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