Why string alias is invariant ?

Sean Kelly sean at f4.ca
Thu Jan 31 08:10:36 PST 2008


Janice Caron wrote:
> On Jan 30, 2008 11:03 PM, Sergey Gromov <snake.scaly at gmail.com> wrote:
> 
>> P.S.  Many thought mus be put into choosing a return type for a library function.  Because if it returns a unique copy of data it must be char[] so that i'm free to modify it.
> 
> Well, consider again the example of lowercasing a string to see why
> that is not so. If I return the original string (not a copy of it),
> then you are /not/ free to modify it, because there might be other
> pointers to that data. So you must first copy it (using dup) and then
> you can modify the copy. This means that the copy need be done /only
> when it is required/, instead of every single time you call the
> function - so yes, it is an improvement in efficiency.

I'd say that it is an improvement in safety rather than efficiency
because the model assumes the string may be shared and thus enforces
copy on write.  But consider something like this:

    char[] data = cast(char[]) read( "myfile.txt" );
    char[][] lines = splitlines( data );

    foreach( line; lines )
    {
        writefln( tolower( line.idup ) );
    }

In this routine, the programmer knows he is the sole owner of the data
and simply wants to print the contents of a file in lower case
line-by-line.  And to do so the contents of data must be duplicated,
which causes GC churn and may slow the app considerably.  I suppose one
possible fix for this sample app would be to convert the entire file to
lowercase in one shot, thus incurring only one copy, but in a real app
it may not be apparent or even possible to modify the algorithm in such
a way.


Sean



More information about the Digitalmars-d mailing list