Small Buffer Optimization for string and friends

Jakob Ovrum jakobovrum at gmail.com
Mon Apr 9 08:50:23 PDT 2012


On Monday, 9 April 2012 at 15:37:37 UTC, Andrej Mitrovic wrote:
> On 4/9/12, Jakob Ovrum <jakobovrum at gmail.com> wrote:
> The one taking (const(char)[] s) does this, but not the other 
> overload
> taking (string s). Whether or not that's safe I don't really 
> know.
> I've had an argument over this on github, but I don't know if 
> it was
> about toStringz or maybe toUTF16z. I haven't got the link to the
> discussion.

You're right, I just confirmed the optimization is still in place 
for the `string` version. The documentation is identical for both 
functions. I think this is a mistake.

It assumes that the string is either a compiler-generated literal 
or a GC allocated string, while the documentation does not 
mention such assumptions. With all the focus on manual memory 
management and pluggable allocators going on, I think the 
optimization must be removed or the documentation for the 
`string` overload changed.

This optimization can always be put back in without narrowing the 
scope of the `string` overload once the above conditions can be 
reliably checked.

Another option is to add a known-bug section to the `string` 
overload informing users that the function may fail on 
custom-allocated strings.


More information about the Digitalmars-d mailing list