V2 string
Sean Kelly
sean at f4.ca
Thu Jul 5 08:45:11 PDT 2007
Derek Parnell wrote:
> On Thu, 05 Jul 2007 00:15:41 -0700, Sean Kelly wrote:
>
>> Derek Parnell wrote:
>>> I'm converting Bud to compile using V2 and so far its been a very hard
>>> thing to do. I'm finding that I'm now having to use '.dup' and '.idup' all
>>> over the place, which is exactly what I thought would happen. Bud does a
>>> lot of text manipulation so having 'string' as invariant means that calls
>>> to functions that return string need to often be .dup'ed because I need to
>>> assign the result to a malleable variable.
>> So just use char[] instead of 'string'. I don't plan to use the aliases
>> much either.
>
> It's not so clear cut. Firstly, a lot of phobos routines now return
> 'string' results and expect 'string' inputs.
I'd argue that the parameters should be "const char[]" rather than
"string", and it's hard to say for the return values.
> Secondly, I like the idea of
> general purpose functions returning 'const' data, because it helps guard
> against inadvertent modifications by the calling routines. It is up to the
> calling function to explicitly decide if it is going to modify returned
> stuff or not.
>
> For example, if I know that I'll not need to modify the 'fullpath' then I
> might do this ...
>
> string fullpath;
>
> fullpath = CanonicalPath(shortname);
I would say that whether the return value is const/invariant indicates
ownership. If the called function/class owns the data then it is const
or invariant. If it does not then it is not const/invariant. This
seems to largely limit "string" as a return value to property methods.
> However, if I might need to update it ...
>
> char[] fullpath;
>
> fullpath = CanonicalPath(shortname).dup;
> version(Windows)
> {
> setLowerCase(fullpath);
> }
>
> The point is that the 'CanonicalPath' function hasn't got a clue what the
> calling function is intending to do with the result so it is trying to be
> responsible by guarding it against mistakes by the caller.
Right. See above.
Sean
More information about the Digitalmars-d
mailing list