Re: Requesting endorsements of Boost.STLInterfaces for review

From: Zach Laine (whatwasthataddress_at_[hidden])
Date: 2019-08-27 20:18:59

On Tue, Aug 27, 2019 at 3:01 PM JeanHeyd Meneide <phdofthehouse_at_[hidden]>
wrote:

>
>
> On Tue, Aug 27, 2019 at 2:50 PM Zach Laine via Boost <
> boost_at_[hidden]> wrote:
>
>> On Thu, Aug 22, 2019 at 9:11 PM Zach Laine <whatwasthataddress_at_[hidden]>
>> 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