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 information: - Your name
Arthur Gruzauskas
- 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?
very straightforward. 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 containers
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 name container_interface. 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 containers? 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
Thanks, Barrett
My one small concern is in the required method: constexpr auto operator-(repeated_chars_iterator other) const noexcept instead of: 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 fine. 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. Arthur