[container] static_string ?

classic Classic list List threaded Threaded
51 messages Options
123
Reply | Threaded
Open this post in threaded view
|

[container] static_string ?

Boost - Dev mailing list
Beast has static_string which someone has asked to be move, is there
any interest in moving this to Boost.Container?

See:

<https://github.com/boostorg/beast/issues/1691>

<https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552448a/include/boost/beast/core/static_string.hpp>

--
Regards,
Vinnie

Follow me on GitHub: https://github.com/vinniefalco

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
On Mon, Sep 9, 2019 at 9:59 AM Vinnie Falco via Boost <[hidden email]>
wrote:

> Beast has static_string which someone has asked to be move, is there
> any interest in moving this to Boost.Container?
>
> See:
>
> <https://github.com/boostorg/beast/issues/1691>
>
> <
> https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552448a/include/boost/beast/core/static_string.hpp
> >
>

This is of course a question for Ion, but I would like to see this made
more widely available.

Zach

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
On Mon, Sep 9, 2019 at 11:23 AM Zach Laine <[hidden email]> wrote:
> This is of course a question for Ion, but I would like to see this made more widely available.

Another entirely acceptable option (or even a preferred option for
many I am sure) is to put it in its own repository as its own Boost
library. It would have to go through the review process. As its own
Boost library it would be quite modular, it should only need
Boost.Assert, Boost.Config, and whatever provides
BOOST_THROW_EXCEPTION.

Is anyone interesting in going down this route?

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 09/09/2019 20:23, Zach Laine via Boost wrote:

> On Mon, Sep 9, 2019 at 9:59 AM Vinnie Falco via Boost <[hidden email]>
> wrote:
>
>> Beast has static_string which someone has asked to be move, is there
>> any interest in moving this to Boost.Container?
>>
>> See:
>>
>> <https://github.com/boostorg/beast/issues/1691>
>>
>> <
>> https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552448a/include/boost/beast/core/static_string.hpp
>>>
>>
>
> This is of course a question for Ion, but I would like to see this made
> more widely available.

Hi,

Sorry for the delay. I think it's a good idea, it seems a really useful
container. To ease the maintenance, I think we should merge
container::string and container::static_string implementations to reuse
as much as code as we can.

Best,

Ion

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
On Mon, Sep 9, 2019 at 2:04 PM Ion Gaztañaga via Boost
<[hidden email]> wrote:
> ...I think it's a good idea, it seems a really useful
> container. To ease the maintenance, I think we should merge
> container::string and container::static_string implementations to reuse
> as much as code as we can.

I've been discussing this on the C++ Slack and I think a separate
Boost library would be best. There is a growing clamor from users for
more modularity from Boost. Having more fine-grained libraries would
help with this. There are other benefits to having a separate library:

- Separate repository has its own Travis compilation / time limits
- Comprehensive valgrind / sanitizer tests will take less time
- The tests on CI will take less time to complete in general
- Coverage reports would be more meaningful (since they include less code)

A one-line change to, f.ex. Boost.FixedString (provisional name) would
have a faster turn-around time on CI than a one-line change made to
Boost.Container.

Another point worth discussing, is overall compilation performance.
Once of the complaints about Beast is the heavy reliance on templated
algorithms. Some of these Beast algorithms simply cannot be changed
since they operate on concepts. However we identified parts of Beast
that could be made into normal functions, and there is a preprocessor
macro to allow those function definitions to be compiled into their
own library. For example:

<https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552448a/include/boost/beast/http/basic_parser.hpp#L686>

For static_string (alternatively named: fixed_string) it should be
very practical to make most of the implementation consist only of
ordinary (non-template) functions, at least for the most common
template parameter of char_traits<char>. We could make the header-only
compilation mode also available via macro as shown above. This will
make static_string very lean in terms of compilation resources and
increase the appeal of the library.

Regards

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
On 10/09/2019 09:42, Vinnie Falco wrote:
> I've been discussing this on the C++ Slack and I think a separate
> Boost library would be best. There is a growing clamor from users for
> more modularity from Boost. Having more fine-grained libraries would
> help with this.

+1

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le lundi 09 septembre 2019 à 23:03 +0200, Ion Gaztañaga via Boost a
écrit :

> On 09/09/2019 20:23, Zach Laine via Boost wrote:
> > On Mon, Sep 9, 2019 at 9:59 AM Vinnie Falco via Boost <
> > [hidden email]>
> > wrote:
> >
> > > Beast has static_string which someone has asked to be move, is
> > > there
> > > any interest in moving this to Boost.Container?
> > >
> > > See:
> > >
> > > <https://github.com/boostorg/beast/issues/1691>
> > >
> Sorry for the delay. I think it's a good idea, it seems a really
> useful
> container. To ease the maintenance, I think we should merge
> container::string and container::static_string implementations to
> reuse as much as code as we can.

As i recently had to write one, i raise another hand for a
static_string in boost.

One thing that was important for me was trivially_copyable property. It
can be quite hard to achieve when sharing implementations (static
vector, for example, lacks this property while it could offer it for
trivial T).

Regards,

Julien


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> On 9. Sep 2019, at 23:03, Ion Gaztañaga via Boost <[hidden email]> wrote:
>
> On 09/09/2019 20:23, Zach Laine via Boost wrote:
>> On Mon, Sep 9, 2019 at 9:59 AM Vinnie Falco via Boost <[hidden email]>
>> wrote:
>>> Beast has static_string which someone has asked to be move, is there
>>> any interest in moving this to Boost.Container?
>>>
>>> See:
>>>
>>> <https://github.com/boostorg/beast/issues/1691>
>>>
>>> <
>>> https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552448a/include/boost/beast/core/static_string.hpp
>>>>
>>>
>> This is of course a question for Ion, but I would like to see this made
>> more widely available.
>
> Hi,
>
> Sorry for the delay. I think it's a good idea, it seems a really useful container. To ease the maintenance, I think we should merge container::string and container::static_string implementations to reuse as much as code as we can.

This was probably discussed here before, but could someone remind me why static_string and static_vector need to exist as separate containers at all? Why don't we use a boost::vector and boost::string with a special allocator that offers a fixed-sized memory pool allocated from the stack?

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
"Hans Dembinski via Boost" <[hidden email]> – 10 septembre 2019 11:07
 
> This was probably discussed here before, but could someone remind me why
> static_string and static_vector need to exist as separate containers at all?
> Why don't we use a boost::vector and boost::string with a special allocator
> that offers a fixed-sized memory pool allocated from the stack?

This is how static_vector is implemented, afaik.

The main drawback is that it makes static_vector not trivially_copyable even for trivial T. I ended up reimplementing a custom static_vector for this reason only.

I don't think it makes much sense to have a static_string which is not trivially copyable (which would probably be the case if using a specialization with an allocator).

Regards,

Julien

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list


> On 10. Sep 2019, at 12:19, [hidden email] wrote:
>
> "Hans Dembinski via Boost" <[hidden email]> – 10 septembre 2019 11:07
>
>> This was probably discussed here before, but could someone remind me why
>> static_string and static_vector need to exist as separate containers at all?
>> Why don't we use a boost::vector and boost::string with a special allocator
>> that offers a fixed-sized memory pool allocated from the stack?
>
> This is how static_vector is implemented, afaik.

You are right,
https://www.boost.org/doc/libs/1_71_0/doc/html/boost/container/static_vector.html

It would be nice if dtl::static_vector_allocator was part of the public interface.

It seems that static_vector could just be an alias template in C++11.

> The main drawback is that it makes static_vector not trivially_copyable even for trivial T. I ended up reimplementing a custom static_vector for this reason only.
>
> I don't think it makes much sense to have a static_string which is not trivially copyable (which would probably be the case if using a specialization with an allocator).

That is an interesting point.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
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?

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
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.

So long as it's not called static_string, because it's not, I'm for this.

Incidentally, over at WG14 we were discussing a mutable string view
object built into the C language. Ours is nothing like this, however.

Niall

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
> Von: "Niall Douglas via Boost" <[hidden email]>
> 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.

Mike

>
> Niall
>

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
On Tuesday, September 10, 2019, Mike  wrote:

> > Von: "Niall Douglas via Boost" <[hidden email]>
> > 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.
>
>
>

Correct.

Glen

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Vinnie Falco wrote:
> Beast has static_string which someone has asked to be move, is there
> any interest in moving this to Boost.Container?

Having this outside Beast would certainly make it more
discoverable!

I have been making a lot of use of boost::container::small_vector
and boost::container::static_vector recently.  A first thought is
that one could wrap those in a vector-to-string adaptor to get
small and static strings (and I have a string_facade class
template that does much of that).  I think it would be useful to
have a small_string implemented like this, but it's not the best
solution for static_string.

I note that the current Beast static_string stores a size_t and
an array of chars.  This is the right approach; it makes it
trivially-copyable.  But if small size is an aim (and I think it
should be), we can do better; when N < 256, use a uint8_t for the
size.  In fact, use boost::integer::uint_t< log2<N> >::least and
get an optimal type for the size.

I have just been looking at an old FixedString class that I wrote
a few years ago, which is very much like the Beast static_string.
The only other feature I added was an on-overflow policy template
parameter, allowing you to throw, assert, truncate or UB on
overflow.  I don't know if I ever really used that.


Regards, Phil.





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On 10/09/2019 13:32, Mike via Boost wrote:

>> Von: "Niall Douglas via Boost" <[hidden email]>
>> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
On Tue, Sep 10, 2019 at 6:15 AM Phil Endecott via Boost
<[hidden email]> wrote:
> I note that the current Beast static_string stores a size_t and
> an array of chars.  This is the right approach; it makes it
> trivially-copyable.  But if small size is an aim (and I think it
> should be), we can do better; when N < 256, use a uint8_t for the
> size.  In fact, use boost::integer::uint_t< log2<N> >::least and
> get an optimal type for the size.

Optimizing for size is not something that I considered, but this would
be possible as per your suggestion.

However, I am interested in a different direction - I'd like to make
as much of the implementation based on ordinary functions (i.e.
non-template) as possible. I often hear complaints from people about
the use of templates in Beast, and in Asio and Networking TS. While
these remarks are often uninformed there are some legitimate concerns,
primarily that compilation resources (both time and space) are
increased.

Some ideas include:

* Remove the CharT and Traits template types, who uses these anyway?

* Derive the fixed_string template (which provides the capacity) from
a non-template base class with one pure virtual member, this member is
provided by the derived class and returns the base pointer, size, and
capacity, to permit the optimizations of small size. This of course
adds a pointer (8 or 4 bytes) to the size...

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
The container is now called fixed_string and I have made a new
repository for it:

<https://github.com/vinniefalco/fixed_string>

It can be used without Beast, only requiring a few utility headers
from Boost such as config, assert, etc..

There are javadocs in the source code but I am still working on
integrating docca (a tool which converts javadocs into Boost Quickbook
output to produce a reference). The tests pass, and there is Travis
integration.

What now? Do we want to propose this for Boost?

Thanks

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list

> On 11. Sep 2019, at 21:06, Vinnie Falco via Boost <[hidden email]> wrote:
>
> The container is now called fixed_string and I have made a new
> repository for it:
>
> <https://github.com/vinniefalco/fixed_string>

IMHO, the name fixed_string is worse than static_string, and it is inconsistent with boost::static_vector.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [container] static_string ?

Boost - Dev mailing list
On Thu, 12 Sep 2019 at 11:14, Hans Dembinski via Boost
<[hidden email]> wrote:
> > On 11. Sep 2019, at 21:06, Vinnie Falco via Boost <[hidden email]> wrote:
> >
> > The container is now called fixed_string and I have made a new
> > repository for it:
> >
> > <https://github.com/vinniefalco/fixed_string>
>
> IMHO, the name fixed_string is worse than static_string,

+1

> and it is inconsistent with boost::static_vector.

Interestingly, it to be named fixed_capacity_vector, renamed in revision 2
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0843r2.html

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
123