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

On Tue, Aug 27, 2019 at 2:50 PM Zach Laine via Boost 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 Sincerely, JeanHeyd