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<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@cplusplusguy.com <nevin@eviloverlord.com>> +1-847-691-1404