December 2019 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

What happened to Boost.Nowide?
by Alexander Grund 08 Jan '20

08 Jan '20

Hi, I'm a user of (a fork of) Boost.Nowide and already fixed some issues I found and was looking into getting them upstream. I also wanted to know, if it is finally in Boost. Unfortunately this does not seem to be the case. I found https://lists.boost.org/Archives/boost//2017/06/236475.php which accepted it into Boost. This is from mid-2017 and nothing has happened since. Does anyone know what the status of Boost.Nowide is? It seems the filestream parts are now incorporated into Boost.FileSystem. So it seems only cin/cout/cerr, the args wrapper and the C-functions (fopen, ...) are missing. Especially the first 2 are very useful in writing cross-platform code. Might those be integrated into some other Boost Library? Thanks, Alex

4 16

Boost ASIO
by live man 03 Jan '20

03 Jan '20

Hi, We have been using Boost for our firmware product which runs in ARM processor. However for development we make use of Visual Studio IDE. We also have our own TCP / IP suite which defines its own socket.h file. We are facing issue related to using Boost ASIO in Windows development platform. It seems that the library by default includes windows networking header files - which we do not want. Instead we want Boost ASIO to make our own library socket headers and declaration. We noticed that if we include Boost ASIO and our TCP / IP socket declaration we get re-definition error and compilation fails with lots of errors? Please let us know how we can resolve the issue with the objective mentioned above? Thanks in advance. Regards, Prakash

2 2

Recomended way of generating documentation
by Alexander Grund 01 Jan '20

01 Jan '20

Hi, I'm currently in the process of generating documentation in a Boost usable format and got a couple questions. The documentation is currently in-source in Doxygen format and has a markdown file for the start page. 1. Which aliases do I need and for what? I've seen boostdoc and boostrelease but couldn't find a description what and why they are 2. Where do the documentation files need to go? It seems using BJam naively outputs them to bin.v2 not to the libraries doc folder which I'd even see useful because generated files should not clobber the source tree 3. What benefit is there going from Doxygen (over multiple conversions) to boostbook? Can't I just go from Doxygen to HTML? 4. If the above: Calling `doxygen mylib.html` in BJam generates a mylib folder and a mylib.html redirecting into that folder. Both hardcoded to go into a subfolder of bin.v2. How is that useful/useable? Wouldn't I want a 'html' folder and an index.html redirecting to the index.html contained or no redirection file at all? 5. As I'm thinking about calling doxygen manually: Do I need to do anything so e.g. mylib shows up in boost/doc/html? Why is only a subset of the libraries there? Thanks for any help or pointers! Alexander Grund

6 5

Boost-GIL GSOC 2020
by Siddhartha Sen 31 Dec '19

31 Dec '19

Hello, I would like to propose an idea for GSOC 2020. I would like to re-implement pre existing features in Boost-GIL for example inverting an image, conversion from black and white to colour and vice versa, etc, but with the usage of parallel programming in order to improve the efficiency and speed things up. This is nothing but an idea merely, as I have some idea with parallel programming beforehand. Could anyone give me some guidance as in how to proceed with this? And also do you all think this is a good enough proposal? I already have built a couple of libraries for image conversion using openmp, but I am not sure whether they are boost compatible or not. Thank You.

2 1

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Andreas Wass 28 Dec '19

28 Dec '19

This my small review of STLInterfaces, and mainly iterator_interface > - Your name Andreas Wass > - Your knowledge of the problem domain I implement mainly iterators every once in a while, both at work and for personal projects. I have mainly used iterator_interface but used container_interface as well. > - Whether you believe the library should be accepted into Boost (be clear > about this) Yes, it helps cutting down on the amount of boilerplate to write. > In addition, you are strongly encouraged to answer the following questions: > - What is your evaluation of the library's > * Design? The design seems solid > * Implementation? Looks solid as well, only had one issue with container_interface (see below). > * Documentation? It is ok. As someone who isn't implementing containers all that often it would be nice to have signatures as well as expressions listed in the container_interface documentation > - Did you attempt to use the library? If so: > * Which compiler(s)? MSVC 2017 and GCC 9 > * What was the experience? Any problems? One problem with container_interface. See https://github.com/tzlaine/stl_interfaces/issues/12 > - How much effort did you put into your evaluation of the review? About two hours implementing iterators and a container

4 5

[review][STLInterfaces] STLInterfaces review results
by Barrett Adair 26 Dec '19

26 Dec '19

Many thanks are owed to all who participated in the formal review of Zach Laine's STLInterfaces library, especially during this busy holiday season: * Hadriel Kaplan - ACCEPT * Andreas Wass - ACCEPT * Rainer Deyke - ACCEPT * Arthur Gruzauskas - ACCEPT * Krystian Stasiowski - ACCEPT * Daniela Engert - CONDITIONALLY ACCEPT * Gavin Lambert - Technical comments First, a summary of the reviews: 1. Design Reviewers were unanimous in their appreciation for the design. Krystian had the only asterisk about the design, noting that derived class members should ideally be SFINAE-detected, where the library feature would SFINAE where the corresponding required derived feature detection fails. I have a different opinion about this, but we can discuss that elsewhere. 2. Implementation The container_interface destructor and the optional dependency on cmcstl2 were snags for multiple reviewers. Several compile errors were discovered that need to be addressed. 3. Documentation Reviewers found the documentation to be "ok". A common request was for better organization of derived-class requirements, particularly with the container_interface template. Reviewers also lamented the lack of training wheels for the subject matter. 4. Tests Hadriel noted the lack of non-copyable value_type tests, while Daniela noted the lack of Boost.Build support. Hadriel was the only one who commented on the quality of tests ("good"), and the only one who ran them. Arthur did his own testing, to satisfaction. I appreciate the presence of SFINAE-friendliness tests and the continuous integration. 5. Usefulness Reviewers appreciated the usefulness of the library. Arthur is "using it happily", while others found it "very useful", "fairly useful", or of "high" usefulness. However, Krystian's response implied that this library may not be as useful for containers needing extreme performance. The reviews clearly demonstrate a consensus. Accordingly, I'm pleased to announce that STLInterfaces is CONDITIONALLY ACCEPTED as a Boost library. Conditions for acceptance: 1. Remove optional dependency on cmcstl2 (issue #27) 2. Add Boost license comments to all files, including appveyor.yml, .travis.yml, README.md, */CMakeLists.txt (issue #26) 3. Support Boost.Build (issue #25) 4. Replace googletest with Boost equivalent (issue #24) 5. Remove usage of non-existent v2_dtl members in container_interface.hpp (issue #22) 6. Include <tuple> for std::tie usage in C++14 mode (issue #21) 7. Fix dangling parens in container_inteface.hpp:731 (issue #20) 8. Make Concepts usage C++20-conformant (issue #13) 9. Remove the destructor in container_interface (issue #12) 10. Add tests for non-copyable value types (issue #30) Suggestions: 1. Explicitly document the signatures and return types of functions provided by base class templates (issue #23) 2. Mention the C++20 generator pattern in documentation (issue #19) 3. Document the library's interactions with Ranges (issue #18) 4. Remove unnecessary comments (issue #17) 5. Investigate compile error in VS2015 (msvc 19.0.3) due to issues with noexcept() operator in function overloading (issue #16) 6. Rename container_interface to sequence_container_interface (issue #15) 7. Change the 'contiguous' bool to an enum (issue #14) 8. Document the relationship between value_type operator== and containter_interface-defined operator== (issue #11) 9. Improve table/section names for better navigation of container_interface tutorial (issue #10) 10. Clean up BOOST_STL_INTERFACES_DOXYGEN usage (issue #28) 11. Split up fwd.hpp into multiple headers (issue #29) 12. Document optimization trade-offs of proxy_iterator_interface (issue #30) Rationale: 1. Condition #1 is, I feel, the appropriate default as review manager. If Zach feels strongly about keeping the optional dependency on cmcstl2, we should discuss. 2. Unless the library requirements webpage has fallen out of date, new libraries must still support Boost.Build. 3. A not-so-quick grep of current Boost libraries yields no `gtest` results. I assume that we do not allow googletest as the sole test framework in a library. 4. The other conditions should be self-explanatory. Thank you Zach for your contributions, and I look forward to working with you to add this library into Boost. Regards, Barrett Adair

2 2

[review] [STLInterfaces] STLInterfaces review starts today
by Barrett Adair 26 Dec '19

26 Dec '19

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 - Your knowledge of the problem domain - Whether you believe the library should be accepted into Boost (be clear about this) In addition, you are strongly encouraged to answer the following questions: - What is your evaluation of the library's * Design? * Implementation? * Documentation? * Tests? * Usefulness? - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? 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. - 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

9 15

Re: [boost] [config][build] Doc missing in 1.72
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-24 Glen Fernandes wrote: > Yes. config.htm was a file in boostorg/config until recently. > > Now that it has been removed, meta/libraries.json's documentation > entry needs to be updated: > https://github.com/boostorg/config/blob/develop/meta/libraries.json#L5 > > From "config.htm" to "doc/html/index.html". > > Glen Fixed on develop: https://www.boost.org/doc/libs/develop/libs/libraries.htm (The Config link now goes to the Config documentation). Glen

4 4

Merry Christmas All...
by Ggh 25 Dec '19

25 Dec '19

Hi, Merry christmas to all of you. Happy holidays Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them.

1 0

(no subject)
by Glen Fernandes 25 Dec '19

25 Dec '19

On 2019-12-19 Niall Douglas wrote: > On 18/12/2019 13:51, Glen Fernandes wrote: >> I've fixed the macros in: >> * boostorg/multi_array >> * boostorg/iterator >> * boostorg/parameter >> * boostorg/polygon > > Thanks! > > I reckon with the above about two thirds of the libraries listed at > https://github.com/boostorg/boost/issues/352 are fixed now. > > Niall In addition to the four above, I've now also fixed: * boostorg/bimap * boostorg/lambda * boostorg/graph * boostorg/property_map The rest of the libraries have active maintainers so they should be able to take care of them. Glen

1 0

[config][build] Doc missing in 1.72
by Edward Diener 24 Dec '19

24 Dec '19

In the 1.72 distribution the documentation for config and build are missing.

3 5

[review][fixed_string] FixedString review results
by Joaquin M López Muñoz 22 Dec '19

22 Dec '19

These are the results of the candidate Boost.FixedString review. Thanks to all the people (and there's been many) who contributed. To clear up the tension, let me begin by announcing that: Candidate Boost.FixedString is ACCEPTED into Boost. Acceptance is subject to the authors' addressing of some issues raised during the review that I label as "priority 1" below. *Summary of reviews* We've had 10 full reviews: * Accept: Deniz Bahadir, Emil Dotchevski, Gavin Lambert, JeanHeyd Meneide, Paul A. Bristow, Peter Dimov, Peter Koch Larsen. * Conditionally accept: Zach Laine. * Reject: Andrzej Krzemienski, Phil Endecott. Zach's conditions to acceptance seem minor and easily addressable to me. Andrzej based his rejection on a perceived lack of clarity as to what the actual pitch of the library is, which ultimately boils down to the issue of throwing/asserting on capacity overflow: my impression is that a strong pitch, if not a universally acclaimed one, emerged during discussions. Finally, Phil voted to reject but then went on to state that he would accept based on a number of "minimally sufficient" conditions that are trivial to meet (or even have been already implemented by Krystian). All in all, I think it is a reasonable compromise to grant acceptance based on the resolution of a number of important issues, listed below. *Issues* I've classified issues in three different priorities: * Priority 1: to be solved *before* inclusion into Boost. * Priority 2: to be addressed somewhere in the future. * Priority 3: anecdotal or without clear support from the community, to be addressed at the authors's discretion. * Priority 1 issues* 1. CMakeLists.txt should either be made generic or removed from repo (it is currently a specific thing for Visual Studio). 2. Choose a name for the component. Some consensus arose that naming should follow std::string's and be of the form basic_foo<...> with aliases foo, wfoo, etc. As for "foo", the following candidates have been proposed: * static_string * fixed_capacity_string * array_string * static_capacity_string * inplace_string * capped_string * bounded_capacity_string * bounded_string To be clear, I don't think any of these is clearly more popular than the rest, so it is up to the authors to make up their mind. 3. constexpr as much as possible, taking into account that, pre C++20, this requires zero initialization of the data array. 4. noexcept as much as possible and, in principle, at least as much as std::string. 5. Provide hash overloads. Up to the authors if they want to cover Boost.Hash as well. 6. Determine the exact behavior on capacity overflow. I think *some* partial consensus arose around throwing via boost::throw_exception so as to provide an opt-out mechanism for exception-handicapped scenarios. This has been the most contentious issue during the review but I think the authors are in their right to decide on throwing much as anyone can decide otherwise and propose what would be basically a different library. 7. Make substr return a fixed_string rather than a view, and additionally provide a view-returning subview member function. 8. State clearly on the docs what C++ version is required. 9 There are wrong "size() + m > max_size()" checks (they could overflow) in the code. 10. to_fixed_string should be a set of overloads mathing those of std::string. 11. There's an issue around some detail::is_input_iterator alias that Zach asked be clarified. 12. Compile-fail tests should be added to verify that those functions with constraints are correctly constrained. *Priority 2* 13. Determine if fixed_string<0> should be specialized or not to make it more memory efficient. This raises potential issues in the uniqueness of the pointer returned by data(). 14. Determine if operator+(fixed_string,fixed_string) should be provided. My impression is that people generally wanted this, and I've been tempted to raise this to priority 1. 15. Optimize the type of the internal size data member when size_t is larger than necessary. 16. BOOST_FIXED_STRING_USE_BOOST is unconditionally defined within the code. The authors should clearly state what this is for and let the user configure the library to use with/without Boost or, else, remove the thing entirely. 17. Source code organization (three equally named files, detal and impl folders), raised some eyebrows. Some (including Vinnie) favor a single-file implementation. 18. Docs should be more C++ standard-like and provide a synopsis. Vinnie has indicated they may abandon Doxygen in favor of asciidoc to produce better-quality docs. In general, people were not enthusiastic about the documentation. 19. The current monolithic test should be split up in lighter, more manegeable test files. Peter Dimov suggested some additional improvements on the testing part. * Priority 3* 20. Provide a literal operator"" 21. Should traits parameter be removed? 22. Store size (as capacity-size) in the last char of the data array, so as to save one memory byte. This might affect performance, though. 23. Add functions for checking remaining capacity. Thanks to Krystian and Vinnie for their work! And to everybody who has contributed to this really interesting review. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

7 12

[gsoc2020] New here
by Siddhant Jain 22 Dec '19

22 Dec '19

Hi, my name is Siddhant I am a first year CS student at IIIT Hyderabad. I am interested in learning more about and contributing to boost. I have visited the obvious beginners links but I am unable to grasp the library to the level where I can contribute code. What would be the suggest plan of action to get comfortable with reading and write code used in boost. I am interested in working on Boost.geometry and/or Boost.real. Thanks

1 0

[move][core] boost::swap() vs boost::adl_move_swap()
by Andrzej Krzemienski 21 Dec '19

21 Dec '19

Hi Everyone, I am seeking an advice. I recently got this pull request: https://github.com/boostorg/optional/pull/77 changing the boost::swap() to boost::adl_move_swap() because it should compile faster. Is there any recommendation for Boost libraries which one to prefer and under what circumstances? boost::adl_move_swap() seems to allow moves rather than copies in more cases. On the other hand boost::swap() seems to have other improvements, like BOOST_GPU_ENABLED. Regards, &rzej;

2 1

boost::python::def_visitor alignment / padding crash.
by Janek Kozicki 20 Dec '19

20 Dec '19

I have discovered an alignment related bug in boost::python::def_visitor For a very detailed description see https://gitlab.com/libeigen/eigen/issues/1795 * a minimal failing example: https://gitlab.com/cosurgi/minieigen-real/blob/minimalFailingExample/src/mi… * and the failing CI pipeline: https://gitlab.com/cosurgi/minieigen-real/pipelines/104745741 Initially I thought that it was related with libeigen. But it turns out that it crashes even without libeigen, when just using boost::multiprecision::float128. The code crashes with g++ 8.3.0 and works with g++ 9.2.1 boost version 1.67 is used there. should I open an issue on boost github? best regards -- # Janek Kozicki http://janek.kozicki.pl/

1 1

[appveyor] Really slow turnover
by Edward Diener 20 Dec '19

20 Dec '19

When I started out in computer programming some 40 years ago you could submit a job, with some JCL, on an IBM mainframe computer via an input card reader and you were lucky if you got back the result a day later. How happy I was when I went to microcomputers and could get almost instantaneous results from any programming attempt. Fast forward to now, some 40 years later, and it seems like nothing changes, despite the great advancement in computer technology and online access in our current age. Attempting to run CI using Appveyor literally has jobs queued pending a run for days and days. Surely there must be something better in this day and age than this ridiculously slow internet service. Is it 1979 again ?

7 18

[review][STLInterfaces] review extended to Dec. 23
by Barrett Adair 20 Dec '19

20 Dec '19

The formal review of STLInterfaces is extended to December 23. Please consider submitting a review if you can.

1 0

Re: [boost] Jason is getting MARRIED!
by Bjorn Reese 20 Dec '19

20 Dec '19

On 11/16/19 7:09 PM, Vinnie Falco via Boost wrote: > My JSON library is going to propose to Boost soon, is there anyone who > might be willing and able to function in the role of review manager? Before we get to that point, there are some questions that the community should address. These days there are a huge number of JSON libraries out there. Some focus on features (e.g. binary JSON or JSONPath), others on performance, and others on user-friendliness. What competitive edge should a potential Boost JSON library offer? Which use cases should a potential Boost JSON library support? Should the library work seemlessly with standard algorithms? Should it be possible to create parser combinators? Should there be a JSON archive for Boost.Serialization? Should it replace parts of Boost.PropertyTree? PS: On a procedural note, you need an endorsement of the library before seeking a review manager.

10 68

GSoc 2020
by Aniswar SK 19 Dec '19

19 Dec '19

Hello everyone, I am Aniswar Krishnan, a 2nd year Computer Science student at Indian Institute of Technology, Madras. I am have been coding in c++ and python for the past 15 months. I am interested in Mathematics and Algorithms and have done courses on same along with Data Structures, Linear Algebra. I got interested int the projects like Boost.Real and Boost GIL and would like to contribute more to the community. Please guide me and share the relevant resources needed. Will be grateful. Regards, Aniswar Krishnan II Year Computer Science IIT Madras Chennai, Tamil Nadu

3 2

Re: [boost] Proposed legacy macro renaming policy
by Glen Fernandes 18 Dec '19

18 Dec '19

I've fixed the macros in: * boostorg/multi_array * boostorg/iterator * boostorg/parameter * boostorg/polygon Glen

2 1

What to do about Boost libraries which use user-defined macros which are not BOOST_ prefixed
by Niall Douglas 18 Dec '19

18 Dec '19

Acting on guidance given to my recent supply to this list of unprefixed macros, namespaces etc injected into the global namespace by Boost, I have logged a list of all issues with each library, and linked to all those from a single issue logged at https://github.com/boostorg/boost/issues/352. A problem has arisen which requires input from boost-dev. Some Boost libraries define as part of their public API a non-BOOST_-prefixed macro which changes the definition of their header files e.g. PHOENIX_LIMIT (just to be clear, Phoenix is not the only library doing this) If we change such macros to be like BOOST_PHOENIX_LIMIT instead, all existing code using Boost which sets PHOENIX_LIMIT would potentially *silently* break. What we could decide to do instead is: #if defined(PHOENIX_LIMIT) && !defined(BOOST_PHOENIX_LIMIT) #error In Boost 1.xx PHOENIX_LIMIT was renamed to BOOST_PHOENIX_LIMIT. Please upgrade your code to reflect the new name. #endif Or one could just leave PHOENIX_LIMIT named as is. What would Boost developers prefer we do? Niall

8 19

Re: [boost] [review] [STLInterfaces] STLInterfaces review starts today
by Hadriel Kaplan 18 Dec '19

18 Dec '19

Howdy, For this review I've really only tried out the iterator_interface part. I'm sorry I can't provide feedback on the container_interface nor view_interface, as I just don't have the free cycles. > - Your name Hadriel Kaplan > - Your knowledge of the problem domain I've been using boost's iterator_facade and adaptor for a long time; I've written my own custom iterators as well, of both traditional and proxy-types. The usual stuff. > - Whether you believe the library should be accepted into Boost (be clear about this) Definitely. It could use word-smithing and minor cleanup stuff, but presumably that happens later. (?) > - What is your evaluation of the library's > * Design? Good overall. > * Implementation? Good. I've got some nitpicks, but honestly none are a big deal. minor nitpicks: 1) I didn't use the proxy_iterator_interface one, only looked at the code. The proxy_arrow_result storing a local T value that it only returns a pointer to, means it's not optimal in some cases. Obviously for something like std::vector<bool> it won't matter, but some value-types are not so lightweight. On the other hand, it looks like we can specialize this for our type (or not even use proxy_arrow_result to begin with)? 2) Can the stuff in fwd.hpp be split out? I could be wrong, but I don't think most of it is needed/used by iterator_interface, and only used by the other two, correct? Reducing what gets included would be nice, for people who don't need the container/view stuff. The old boost iterator_facade/adaptor headers included so much that it drove some people to stop using them; for example see the comments here: https://github.com/facebook/folly/blob/master/folly/detail/Iterators.h 3) This lib hasn't been tested for C++20, and obviously can't be yet, but it makes assumptions that it can safely replace some of its internals with C++20's new ones. Things like concepts and ranges. I'm not sure that's advisable, until all the major compilers support them and can be tested. It would be a shame if people using this lib can't upgrade to C++20 because it breaks this lib, until they upgrade boost as well. (not a big deal, just more noting it) 4) The files use a macro to control doxygen output. Is this still required for boost libs? Doxygen has had the cond/endcond commands for a long, long time. It's kinda ugly to see these macros, and kinda silly that everyone's compiler will be evaluating them all the time. (I know that's super-nitpicky) 5) I assume all the _has_include(<stl2/ranges.hpp>) checks will be removed, since that's a thirdparty header? 6) This lib requires C++14, but I don't see a macro checking that anywhere and providing a simple error to the user. 7) I can't decide if the BOOST_STL_INTERFACES_STATIC_ASSERT_ITERATOR_TRAITS() thing is a good idea or a waste of time. I tried it, it passed. But of course it did, because it's just checking that I got the API that I told iterator_interface to create, no? This just seems like needless repetition to me. I mean if I screwed it up to begin with, I'll screw it up in this macro too, no? But maybe I'm missing something obvious. (could be - it's getting late) > * Documentation? It's OK. I enjoyed some of the humor. :) It's missing some info for things that are customization points. For example base_reference() is shown in an example, but not really documented anywhere as far as I can tell. The tables aren't as useful/explanatory as one would hope. I mean I knew what they meant, but I'm not sure someone newer to this area would. (but then again, that's what blogs/articles are for I guess) I think it might also help if there were some explanation for what happens under-the-hood, in terms of what public methods get auto-generated from what, for which iterator types. For example, it's surprising that for a bidirectional iterator the user defines operator==(), but not for random-access iterator. (that particular case happens to be mentioned in a note, but you get my point) There are also typos and such, but I presume that gets checked later. > * Tests? Good. I copied them over and ran them as well. (but not the v2 tests, nor the ones for container_interface or view_interface) I think it would be better if there were some tests for iterator_interface with non-copyable value-types. Testing it only for `int`s is cheating. :) Also, random question: for the container_interface, did you try using it with the boost::fixed_string (or static_string, or whatever it's called)? I mean that _is_ a contiguous container, and it's in boost review too, so might it be a good test candidate? :) > * Usefulness? Very useful. iterator_facade/adaptor were showing their age. It's time for something new and shiny. I was happy that it reduced the number of functions we needed to implement in our current usages from 5 to 3. > - Did you attempt to use the library? Yup. I replaced three existing boost::iterator_facade usages in my company's code-base with this one, to try it out. Ran our unit tests with and without valgrind as well. But to be honest these weren't very complicated iterators. I did _not_ try replacing boost::iterator_adaptor, but I hope to try that eventually. > * Which compiler(s)? (old ones, so I could build my employer's codebase and run all their unit tests...) 1) gcc 7.3.1 with c++17 2) clang 5.0.0 with C++17, using gcc's libstdc++ Both using boost 1.55 (sorry!), with the stl_interfaces headers copied over manually, without using the CMake files in the github repo. Neither compiler has the early Concepts support. > * What was the experience? Any problems? Not really. The hardest part was figuring out the new model of what the derived had to define, compared to iterator_facade. (i.e., I was so used to the old model that it took me a bit to grok this one) > - How much effort did you put into your evaluation of the review? Only a few hours, maybe 4-5 total. Sorry, I wish I had more free time. :( > - Do you like the name container_interface? sequence_container_interface > is more precise, but seems a bit long. I'm not sure the length matters much for this use-case, as it's a one-time thing (generally), and not used by users of the actual container; and can anyway be aliased. (I mean, the "stl_interfaces" sub-namespace is annoying too, but it's not a big deal in my opinion) > - 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. Yes I think so, depending on what it did... but for *unordered* ones (i.e., hash-maps/sets), rather than rb-trees. I often find myself encapsulating them, and then having to write a lot of boilerplate public member functions. And several functions can be boiled down for hash-maps. For example count() and contains() can just use find(). I don't know why an unordered_container_interface wouldn't be do-able, including heterogenous lookups, for various hash-map/set flavors. (except, of course, that boost::unordered_map/set's API is different than std's for heterogeneous lookup; which is unfortunate) -hadriel

1 0

[review] [STLInterfaces] STLInterfaces iterator_interface mini mini review
by Arthur Gruzauskas 18 Dec '19

18 Dec '19

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

3 4