> In Nim string literals do not allocate either, but assignments copy.
I wasn't sure whether "assignments" also meant "let a="abc" so I checked: after
further investigation by inserting logging inside copyString, looks like let
a="abc" does allocate (please correct if I'm wrong):
let a="abc"
Run
generates C code:
...
// this doesn't allocate yet
STRING_LITERAL(TM_4dVrjrGda9bN4zEljhxY9bVg_4, "abc", 3);
...
// but this does allocate; calls copyString => allocStrNoInit =>
newObjNoInit
a = copyString(((NimStringDesc*) &TM_4dVrjrGda9bN4zEljhxY9bVg_4));
Run
looking at the addresses via repr(a[0]) and comparing to ones of a GC-allocated
string also confirms this (the addresses are similar, not from ROM).
* Wha'ts odd is that \--gc:none doesn't show a warning in that case even
though there is an allocation; isn't that misleading?
* eg: so the following will allocate 10 times (in D: 0 times):
for i in 0..n:
let a="abc"
# as you can also see by looking at addresses changing in each iter: echo
repr(unsafeAddr a[0])
Run
> The new string/seq implementation will eliminate more copies.
Great, is there any kind of link/doc/design notes to that work?
* regarding null termination
indeed, all strings are 0 terminated currently in Nim; in my idea of an ideal
string type, null termination would only occur for string literals (not on
slices). I'll write more on this later, it requires a full design writeup to
make sure there are no holes.
