Re: [fixed_string] Why "fixed" rather than "static"?

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2019-11-29 07:44:48

czw., 28 lis 2019 o 15:19 JeanHeyd Meneide via Boost <boost_at_[hidden]>
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.html#idm45836565532720-bb

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
>