Boost logo

Boost :

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
`capacity()` means.

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
some ambiguity.


> Best,
> JeanHeyd
> _______________________________________________
> Unsubscribe & other changes:

Boost list run by bdawes at, gregod at, cpdaniel at, john at