On 4/8/12 10:48 AM, Michel Fortin wrote:
On 2012-04-08 15:06:13 +0000, Andrei Alexandrescu
<seewebsiteforem...@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
