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