From: Arthur Gruzauskas (grattle_at_[hidden])
Date: 2019-12-16 13:42:12
On Wednesday, 11 December 2019 11:21:23 AM AEDT Barrett Adair via Boost wrote:
> Dear Boost,
> The formal review of Zach Laine's STLInterfaces library begins now, and
> will run through December 19. Please participate in this review if you can.
> To submit a review, please reply to this email with the following
> - Your name
> - Your knowledge of the problem domain
I've written a number of iterator interfaces over the years. Nothing fancy,
but have dipped my toes in iterator implementation.
> - Whether you believe the library should be accepted into Boost (be clear
> about this)
ACCEPT, simply because I am using it happily.
but I have only used container_interface, not the rest.
> In addition, you are strongly encouraged to answer the following questions:
> - What is your evaluation of the library's
> * Design?
simple interface, small learning curve, great value for effort.
A small number of methods to implement the essential concepts. A small enough
concept chunk to be easily manageable.
simple to use, just copied the code in the readme.md and adapted it.
> * Implementation?
worked for me. I didn't examine the code much. I like its layout and it looks
clean to me.
> * Documentation?
The readme.md with that simple example was enough for me to adapt the intro
sample iterator to my code.
I note the example has been criticised by Gavin Lambert a few posts ago. But I
love it as it made everything simple and clear.
Reading the main doc page filled in a few conceptual gaps, but that readme.md
gave me the overview that made the rest easy.
> * Tests?
So far brief tests have all worked well. I did not exhaustively test the
iterators. They also worked fine in a couple STL algorithms. Again, I have only
dealt with iterator_interface.hpp
> * Usefulness?
My experimental class would have stalled for some time if this easy iterator
interface had not been there. Encouraged, I'm now looking at using it for
more complicated structures.
> - Did you attempt to use the library? If so:
> * Which compiler(s)?
clang-8 for c++17 on debian linux.
> * What was the experience? Any problems?
a few small glitches, as I just grabbed iterator_interface.hpp and fwd.hpp
and made small changes for it to work inside my project.
https://github.com/tzlaine/stl_interfaces/issues describes two minor issues,
which could be well related to me just grabbing those 2 files only, outside the
boost structure that would normally sustain it.
> - How much effort did you put into your evaluation of the review?
Several hours reading, adapting and getting it working for me.
> STLInterfaces is a C++14 library targeting ISO standardization. The
> following templates are provided, all C++20-friendly:
> 1. iterator_interface - a modern version of the iterator_facade and
> iterator_adaptor parts of Boost.Iterator
> 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature
> 3. container_interface - a tool to eliminate boilerplate when writing new
> We would appreciate answers to these library-specific questions:
> - Do you like the name container_interface? sequence_container_interface
> is more precise, but seems a bit long.
It doesn't clash with anything in my mental namespace, so I'm happy with the
BTW, I have not used container_interface, I just saw it now and had a look. I
can see this simplifying some upcoming containers, and will certainly be
giving it a go.
view_interface is not something I have a need for currently.
> - Would you use something like container_interface, but for associative
> If so, should it assume a node-based interface, a la std::map
> and std::set? This assumption would preclude alternative associative
> container-like types, such as flat_map.
> Code: https://github.com/tzlaine/stl_interfaces
> Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html
My one small concern is in the required method:
constexpr auto operator-(repeated_chars_iterator other) const noexcept
constexpr auto operator-(const repeated_chars_iterator& other) const noexcept
I may soon have a need for an iterator that holds a lot of state, and copying
that iterator for each subtraction makes me wonder about a performance penalty
in inner loops.
It is not a dealbreaker for this review, and I didn't examine Zach's tradeoffs
for doing it this way. I see many of my use cases where this approach will be
This is my first review, incomplete as it is, mainly motivated because no one
else has done one yet, and because I found iterator_interface useful and want
to encourage Zach for this lovely simplifying interface.
Thanks very much, Zach.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk