czw., 28 lis 2019 o 15:19 JeanHeyd Meneide via Boost
why was this library called fixed_string rather than static_string?
I like the name fixed because when I put it together with the static keyword it seems like less of a mess:
constexpr static static_vector... constexpr static fixed_vector...
I will say I like how the second one reads and static has the connotation of lifetime implications that I'm not sure static_vector or static_string actually do (they're not some sort of shared global-like storage for a thing). I hope both get changed to "fixed", as "static" is a nightmare of overloaded meaning, maybe with an alias "template <...> using fixed_vector = static_vector<...>". (Or we just come up with an even better short word, but I have no ideas for that!)
I agree that "static_" also has the potential to mislead.
Still, existing practice is important...
As pointed out in another thread, static_vector and fixed_string have taken a different design tradeoff regarding on what doing a `resize()` beyond `capacity()` means. static_string treats it as a precondition violation: https://www.boost.org/doc/libs/1_71_0/doc/html/boost/container/static_vector... fixed_string treats it as a correct (albeit rare) usage. (Although it is not documented clearly enough.) The architectural decision is: is it a user that is responsible for maintaining the size() below capacity() (the case of static_vector) or the library (the case of fixed_string). This decision warrants assigning a different prefix to fixed_string. Also, in the light of this, even name `fixed_capacity_string` would leave some ambiguity. Regards, &rzej;
Best, JeanHeyd
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost