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!) Still, existing practice is important... Best, JeanHeyd

czw., 28 lis 2019 o 15:19 JeanHeyd Meneide via Boost napisał(a):

...

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

On Thu, Nov 28, 2019 at 6:19 AM JeanHeyd Meneide wrote:

...static has the connotation of lifetime implications...

"static" is also the opposite of "dynamic" so there's some wiggle room here, I think Regards

Le jeudi 28 novembre 2019 à 15:29 +0100, Hans Dembinski via Boost a écrit :

...

We already discussed the name a bit. At the danger of getting into bike-shedding (but names are important):

Mateusz made the proposal "fixed_capacity_string", which is long but more precise than either static_string or fixed_string.

It is. And i expect users who wish a shorter name to define fc_string as a non ambiguous alias.

I don't find the long name problematic, because I assume that this type wont often appear in interfaces, but rather somewhere deep in the implementation.

+1

Yet another idea:

array_string

This may mislead the reader (at least some non native english ones) into thinking it is an array of string. Array also misses the distinction between size / capacity, thus it does not look like a so good idea (there are places where a fixed_size_string could be useful). static_string has the advantage of consistency with static_vector. But static_vector is not a very good name itself. Regards, Julien