Re: [container] static_string ?

From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-09-10 13:25:09

On 10/09/2019 13:32, Mike via Boost wrote:
>> Von: "Niall Douglas via Boost" <boost_at_[hidden]>
>> 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/b7230f12f16fe7a9f7a1ece5be1f607c8552448a/include/boost/beast/core/static_string.hpp
> 
> 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<char *> 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