Re: [boost] [container] static_string ?

10 Sep 2019

      On 10/09/2019 13:32, Mike via Boost wrote:
...
...
Von: "Niall Douglas via Boost" 
On 10/09/2019 12:40, Niall Douglas via Boost wrote:
...
On 09/09/2019 17:59, Vinnie Falco via Boost wrote:
...
Beast has static_string which someone has asked to be move, is there
any interest in moving this to Boost.Container?
What's the advantage over a string_view?
To answer my own question, it's a mutable string_view.
I thought a static_string is a type that owns the string data, so
nothing like a string_view (mutable or not) at all.
The difference compared to a std::string would be the same as
the difference between std::array vs std::vector i.e. the data is
stored in a fixed buffer inside the type and not on the heap,
which in turn means there is a fixed capacity (configurable via
a template parameter).
Thats exactly what I see in https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c85524...
so I'm not sure, where your comparison to string_view comes
from.
I don't care for the storage owning part at all. If you want that, use a
custom allocator with std::string.

Any time I've written this sort of thing, it's a mutable string view
operating upon an externally managed char array. It has layout of:

class mutable_string_view
{
  char *_begin, *_end, *_capacity;
};

This is trivially copyable. I usually use storage as:

static std::atomic next_mutable_string;

... where the char * points into some buffer I've thrown at the problem.
You atomically increment the atomic pointer by capacity, return a
mutable string view.

Niall