Re: Fixed String review

From: Nevin Liber (nevin_at_[hidden])
Date: 2019-11-27 22:51:49

On Tue, Nov 26, 2019 at 11:34 AM Vinnie Falco via Boost <
boost_at_[hidden]> wrote:

> > - You can add std::hash overloads.
>
> I'm not seeing the value in these features. What's the use case? No
> one will be using static_string as the key for a container, since it
> wastes space.

I've used fixed sized strings not only because they are space efficient,
but also because they are non-allocating.  And because those types were
being used in other places, it was also useful to have them as keys in hash
maps.

> Why do we need a string literal operator, to produce a
> string constant that takes up more space than necessary? And why are
> we "optimizing" the case where size==0? Is this something that anyone
> will notice or care about (aside from WG21 of course, which often
> concerns itself with not-relevant things).

I'm sure people said the same thing about array<T, 0>, yet it turns out to
be useful in generic code.  As for people noticing, they do tend to notice
sub-optimal implementations.

 Given that "'optimizing' the case where size==0" is about implementation
and not specification, this looks like something that WG21 would:

   - consider not-relevant
   - not concern itself with it

Could you elaborate on why you think WG21 would be concerned with it,
should it someday make it into a proposal?

The more interesting argument is whether or not to include reserve() and
shrink_to_fit().  If it is for generic replacement of std::string, then
reserve() should throw when n > size() (it is currently underspecified).
Since it does no allocation I'd leave them out.

-- 
 Nevin ":-)" Liber  <mailto:nevin_at_[hidden] <nevin_at_[hidden]>>
[phone]