From: JeanHeyd Meneide (phdofthehouse_at_[hidden])
Date: 2019-08-27 20:01:11
On Tue, Aug 27, 2019 at 2:50 PM Zach Laine via Boost <boost_at_[hidden]>
> On Thu, Aug 22, 2019 at 9:11 PM Zach Laine <whatwasthataddress_at_[hidden]>
> > 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
> > 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk