Unique vs. shared return values
Steven Schveighoffer
schveiguy at yahoo.com
Fri Feb 3 17:43:58 PST 2012
On Thu, 02 Feb 2012 18:23:13 -0500, Ali Çehreli <acehreli at yahoo.com> wrote:
> strings provide opportunities for optimization. For example,
> std.string.leftJustify() returns
>
> - either a slice of the entire input string when the field is shorter
> than the string (this is an optimization)
>
> - or a new string when the field is larger than the string
>
[snip]
> Of course this is not a criticism of leftJustify(). I face such
> decisions frequently myself. I am curious about what you think about
> functions that *may* return unique data.
>
> Is that a problem for you? Have you developed guidelines to deal with it?
When you have a function that may return an alias to it's parameters, or
it may return new data, there are two very effective ways of dealing with
the possibly non-deterministic result:
1. Treat the resulting data as const explicitly, or force uniqueness by
dup-ing the result: const result = leftJustify(...); auto result =
leftJustify(...).dup;
2. Replace the original alias: a = leftJustify(a, ...);
What you should try to avoid is data that is aliased in two places, and
modifiable.
This is somewhat similar to the non-determinism problem with array
appending.
Of course, another very effective approach is to use immutable strings.
-Steve
More information about the Digitalmars-d
mailing list