From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2019-12-04 23:19:50
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
>> <boost_at_[hidden]> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk