On 10/09/2019 13:32, Mike via Boost wrote:
Von: "Niall Douglas via Boost" <boost@lists.boost.org> 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<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