On 08/05/2011 07:59 AM, Ion Gaztañaga wrote:
El 05/08/2011 1:44, Phil Endecott escribió:
Hi Ion,
I see that your string implementation has a small buffer optimisation (SBO). Have you tried to benchmark this, and/or any of the other design decisions? I vaguely recall that libc++ may have done some measurements but I can't find anything now.
I havent' measured it thoroughly. It's based on the same ideas libc++ uses, and I have no other non-SBO implementation to compare. Maybe an easy task is to compare this string with other standard libraries that use SBO.
Quick question about the SBO: why are you using two static_casts, with one to void* and another to the target type, rather than the more explicit reinterpret_cast? Both have the same effects, but the latter could allow the compiler to issue warnings in case of strict aliasing problems. Unfortunately you cannot put long_t directly in the union (since pointer does not have to be a POD, I take it?), so I'm not sure the code can be made standard-conforming in C++03.
Also, have you considered adding e.g. a ctor that takes a std::string, for interoperability? (I guess the same could be asked for the other types.)
That might be a good addition if there is consensus for that. You can just use target.assign(src.begin(), src.end()) but I think the constructor could optimize some conversions, like ordered containers.
Containers have a constructor that takes two iterators. It might be interesting to extend this by adding a constructor that takes a single range argument.