On Thu, Aug 22, 2019 at 10:14 PM Gavin Lambert via Boost < boost@lists.boost.org> wrote:

On 23/08/2019 14:11, Zach Laine wrote:

...

Online docs:

https://tzlaine.github.io/stl_inteTherfaces/doc/html/index.html https://tzlaine.github.io/stl_interfaces/doc/html/index.html

Speaking of iterators being error-prone (and the ironic typo in the above link):

How'd that get in there? That's weird.

In

https://tzlaine.github.io/stl_interfaces/doc/html/boost_stlinterfaces__propo... the long-form implementation of repeated_chars_iterator::operator>= is not correct.

Thanks. I almost want to leave it for pedagogical reasons.

And operator-(difference_type lhs, repeated_chars_iterator rhs) seems dubious; this operation is normally not commutative. It seems more correct for that operator to not exist.

Yeah, that should not be there.

(And I hope that iterator_interface does not define it either.)

It does not.

There's also several typos sprinkled around, such as "givenn" and using "if" instead of "it", etc.

I just ran a spell-check on the docs. I think I got all the typos. I did not notice the if/it confusion. Where was that?

I haven't read this in detail yet, but it sounds interesting.

Are you planning to add support for AllocatorAwareContainer at a later stage, or is there something that would make that infeasible?

I hate allocators. I will not be adding support for allocator-aware containers. Thanks for the feedback. Does this mean that you'd like to see a review? Zach

On 23. Aug 2019, at 09:22, Gavin Lambert via Boost wrote:

I don't really write new iterators or containers very often, and when I do, it's usually the allocators that are the pain point.

I second that.

On 8/23/19 6:39 PM, Zach Laine via Boost wrote:

Even if I could do something to make allocator-aware containers easier to write, I would not, simply because the whole point of making container_interface is to make container authoring straightforward. If multiple allocation strategies are actually important, write multiple containers, each with the different strategy. The allocation scheme you use is an inherent part of the class's invariant maintenance, despite what the standard library would have you think.

Container properties, like element contiguity, list and complexity of operations, etc., and memory allocator are conceptually distinct. Implementing a container over a non-customizable allocator is viable as long as the allocator fits your use case. Which is unlikely to be the case when the container is part of a public generic library, such as Boost.Whatever. Furthermore, asking people to reimplement the container just to change the allocator is simply unreasonable. Implementation complexity of a container is often higher than that of an allocator, given that it often comes down to one of the function families like malloc/aligned_alloc/free. Even if it doesn't, an allocator should not be part of the container implementation anyway. Standard containers may be unnecessarilly complicated by the current allocator handling convention, but conceptually, that the container and the allocator are separate, is the right design choice.

On 23. Aug 2019, at 21:58, Zach Laine via Boost wrote:

On Fri, Aug 23, 2019 at 2:12 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:

...

On 8/23/19 6:39 PM, Zach Laine via Boost wrote:

...

Even if I could do something to make allocator-aware containers easier to write, I would not, simply because the whole point of making container_interface is to make container authoring straightforward. If multiple allocation strategies are actually important, write multiple containers, each with the different strategy. The allocation scheme you use is an inherent part of the class's invariant maintenance, despite

what

...

the standard library would have you think.

Container properties, like element contiguity, list and complexity of operations, etc., and memory allocator are conceptually distinct. Implementing a container over a non-customizable allocator is viable as long as the allocator fits your use case. Which is unlikely to be the case when the container is part of a public generic library, such as Boost.Whatever.

Furthermore, asking people to reimplement the container just to change the allocator is simply unreasonable. Implementation complexity of a container is often higher than that of an allocator, given that it often comes down to one of the function families like malloc/aligned_alloc/free. Even if it doesn't, an allocator should not be part of the container implementation anyway.

Standard containers may be unnecessarilly complicated by the current allocator handling convention, but conceptually, that the container and the allocator are separate, is the right design choice.

As I stated previously, this discussion is thoroughly moot. I cannot do anything in a CRTP base class like container_interface to help those who want to create allocator-aware containers.

Your feelings about the allocator abstraction -- and mine as well -- are irrelevant to any discussion of stl_interfaces. If you care enough about this debate to start another thread, I'll follow you there.

I think Andrey gave you some very good arguments and we are not discussing personal choices here. Allocators are part of the STL and Boost. You need to adhere to these design choices if you want to write a generic C++ component that may be part of the STL some day. That it is too much effort for you is not a viable argument. Your arrogant and dismissive attitude is not helping your cause either. You are not becoming a first class C++ author by rejecting good advice.

On Mon, Sep 9, 2019 at 6:13 AM Rob Stewart via Boost wrote:

On September 9, 2019 4:08:04 AM EDT, Hans Dembinski via Boost < boost@lists.boost.org> wrote:

...

I think Andrey gave you some very good arguments and we are not discussing personal choices here. Allocators are part of the STL and Boost. You need to adhere to these design choices if you want to write a generic C++ component that may be part of the STL some day. That it is too much effort for you is not a viable argument. Your arrogant and dismissive attitude is not helping your cause either. You are not becoming a first class C++ author by rejecting good advice.

You have completely missed the point. Zach is saying there is nothing that can be done, even if he wanted to do it, because the work has to be done in the derivate.

Zach also is willing to discuss the topic, but doesn't want this thread derailed, which is perfectly reasonable.

Thanks, Rob. That's it exactly. It's not that allocator support is too hard, it's that it cannot be done with a CRTP adaptor. And I'm not trying to be rude, just trying to keep the thread focused. Email after does not convey tone of voice, after all. If I came off as rude or dismissive, I apologize. That was never my intention. Zach

On Sat, Sep 7, 2019 at 12:10 PM Mike via Boost wrote:

I don't think I can formally endorse your library, but as I said before, I'd find something like this very useful and would be happy to see it getting a proper review by the boost community.

Frankly speaking however, if you'd commit to maintaining the library as a standalone project on github (within a different namespace of course), that would be good enough for me.

Thanks, Mike. By the way, what you just did counts as an endorsement. It's nothing formal, it's just an expressed interest in seeing a review. Zach

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

Il mar 27 ago 2019, 20:50 Zach Laine via Boost ha scritto:

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.

[snip]

Just a friendly reminder that this thread exist. :) There was quite a bit of interest when the thread had iterator_facade in the title; this is about that.

Hi Zach, thanks for furthering your work. I would be glad to have something like this in Boost. As soon as possible I want to put your code to test: if there were a review I would try to participate in it. Best Francesco