Re: [boost] [Containers] String performance and compatibility

Subject: Re: [boost] [Containers] String performance and compatibility
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2011-08-05 05:04:20

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.