Re: [boost] Requesting endorsements of Boost.STLInterfaces for review

On Tue, Aug 27, 2019 at 3:01 PM JeanHeyd Meneide wrote:

On Tue, Aug 27, 2019 at 2:50 PM Zach Laine via Boost < boost@lists.boost.org> wrote:

...

On Thu, Aug 22, 2019 at 9:11 PM Zach Laine wrote:

...

As mentioned a couple of weeks ago, I started a small library that was an updated iterator_facade. It is now a still-smallish library called stl_interfaces that includes a pre-C++20 implementation of view_interface, and analogous templates iterator_interface (a cross between Boost.Iterator's iterator_facade and iterator_adaptor), and container_interface.

The before/after for the code is amazing, and that is does retain the same performance profile is great too. I would be very happy to have a library like this, especially after having written a large chunk of different encoding/decoding/transcoding iterators, and a handful of proxy iterators over the last few months.

A pre-C++20 implementation of all of this would be fantastic.

I do not really know how to weigh in on whether or not there should be container interfaces for allocators. There are a large portion of things to consider for allocator aware containers, with everything from strong exception safety to value_type rebinding when necessary to different storage methods for what the container has to do. Having started writing small_bit_buffer and small_buffer (SBO for bits-in-T, and SBO for just a plain T with no bit-based analysis) containers based on T/Alloc recently, I had an incredibly hard time trying to abstract away storage and size concerns in such a way that such things could be implemented in a plain generic fashion that did not incur space/time tradeoffs unacceptable in the places likely to use them.

That is, I don't think allocator_container_interface is at all easy, or doable, as the usage of the allocator is extremely specific to the container you write. The rest of the library is lovely! :D

Thanks, JeanHeyd. I still do not think that I even *could* help. The reason is that the library's CRTP templates can only provide essentially vacuous implementations of functions that can be implemented in terms of the functions you provide. Any of the hairy parts of dealing with allocators would happen in the user-provided portion of the code. The CRTP template would provide one or more of these (from [tab:container.alloc.req], http://eel.is/c++draft/containers#tab:container.alloc.req): allocator_­type get_­allocator() X() X u; X(m) X u(m); X(t, m) X u(t, m); X(rv) X u(rv); X(rv, m) X u(rv, m); a = t a = rv a.swap(b) get_allocator() returns an allocator which is possibly a member variable. It must be user-provided. Member swap() must be user-provided; the CRTP template does not know enough about your type to implement that. The rest are a typedef, and the special members and constructors. The CRTP template cannot help with those either. Zach