Re: [boost] Fixed String review

On Tue, Nov 26, 2019 at 11:34 AM Vinnie Falco via Boost < boost@lists.boost.org> 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, 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 > +1-847-691-1404