Small Buffer Optimization for string and friends

[Andrei Alexandrescu]

On 4/8/12 10:48 AM, Michel Fortin wrote:
> On 2012-04-08 15:06:13 +0000, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> said:
>
>> On 4/8/12 9:59 AM, Michel Fortin wrote:
>>> But as soon as you take a pointer to that string, you break the
>>> immutability guaranty:
>>>
>>> immutable(char)[] s = "abcd";
>>> immutable(char)* p = s.ptr;
>>> s = "defg"; // assigns to where?
>>
>> Taking .ptr will engender a copy. A small regression will be that
>> address of individual chars cannot be taken.
>
> You know, many people have been wary of hidden memory allocations in the
> past.

Well, the optimization makes for fewer allocations total. In fact .ptr 
does the allocation that was formerly mandatory.

> That's not going to make them happy. I'm not complaining, but I
> think .ptr should return null in those cases.

That would be too large a regression I think. And it's not detectable 
during compilation.

> Let people use toStringz
> when they need a C string, and let people deal with the ugly details
> themselves if they're using .ptr to bypass array bound checking. Because
> if someone used .ptr somewhere to bypass bound checking and instead he
> gets a memory allocation at each loop iteration… it won't be pretty.

Only one allocation. First invocation of .ptr effectively changes 
representation.

> And what about implicit conversions to const(char)[]? That too will
> require a copy, because otherwise it could point to the local stack
> frame where your immutable(char)[] resides. That said, maybe copies of
> small-string optimized immutable(char)[] could be small-string optimized
> const(char)[]. That'd not have any side effect since no one can have a
> mutable pointer/slice to the const copy anyway.

I think casting to const(char)[] should work without allocation.


Andrei