On 2019-12-05 01:24, Peter Dimov via Boost wrote:
Krystian Stasiowski wrote:
On Wed, Dec 4, 2019 at 1:24 PM Peter Dimov via Boost
wrote: Yes, probably. As I said, it's not clear that we should bother with it > (I wouldn't), but it at least gives consistent space savings for all > short strings.
That said, one could use it for N < 32, when the size will be in the same cache line.
What should I do? I can implement this, but since `size()` would be have to be called as opposed to simply accessing the member (this already happens, since a proxy function is used due to the specialization for zero size, but it only returns the member each time so it is easily inlined), as Andrey mentioned this may not be cache friendly.
Well as I said, if it were up to me, I wouldn't use this optimization.
smallest_width_t size_; char data_[ N+1 ];
is good enough for me, in all cases, including N == 0. This makes fixed_string<0> two bytes instead of one, but I'm pretty sure I (and 99.4% of the Earth population) can live with that.
I think, fixed_string<0> should be specialized to an empty class. Not that I have a specific use case for fixed_string<0>, but making the class empty in general is useful for EBO and [[non_unique_address]] and e.g. tuples that employ these techniques. If we can attach the attribute to a captured value in a lambda, that'd be useful as well.