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 <
> > - 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
> 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
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]>> +1-847-691-1404
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk