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
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:
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk