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]>
> > 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
static_string treats it as a precondition violation:
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
> Unsubscribe & other changes:
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk