- Boost - lists.boost.org

[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

Unmerged change in boostcpp.jam
by Peter Dimov 17 Dec '19

17 Dec '19

boostcpp.jam on develop contains the following patch, which is not merged to master: diff --git a/boostcpp.jam b/boostcpp.jam index efc41c1ed..299401778 100644 --- a/boostcpp.jam +++ b/boostcpp.jam @@ -607,7 +607,7 @@ rule address-model ( ) return <conditional>@boostcpp.deduce-address-model ; } -local deducable-architectures = arm mips1 power sparc x86 combined ; +local deducable-architectures = arm mips1 power riscv s390x sparc x86 combined ; feature.feature deduced-architecture : $(deducable-architectures) : propagated optional composite hidden ; for a in $(deducable-architectures) { @@ -618,11 +618,13 @@ rule deduce-architecture ( properties * ) { local result ; local filtered = [ toolset-properties $(properties) ] ; - local names = arm mips1 power sparc x86 combined ; + local names = arm mips1 power riscv s390x sparc x86 combined ; local idx = [ configure.find-builds "default architecture" : $(filtered) : /boost/architecture//arm : /boost/architecture//mips1 : /boost/architecture//power + : /boost/architecture//riscv + : /boost/architecture//s390x : /boost/architecture//sparc : /boost/architecture//x86 : /boost/architecture//combined ] ; This seems to add support for "riscv" and "s390x" as architectures. Should this be merged to master?

1 0

Test Matrix not Updating
by Michael Caisse 16 Dec '19

16 Dec '19

We are aware that the test matrix has not been updating. The problem is caused by a server that we do not control. Things should be resolved in the next couple days. Thank you for your patience and sorry about the disruption. michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Enabling warnings for library sources and tests but not for dependencies
by Alexander Grund 15 Dec '19

15 Dec '19

Hi, I want to build at least the tests but better also the library sources itself with warnings enabled and warnings-as-errors to avoid regressions. >From BoostAssert I found the following snipped added to the top of test/Jamfile.v2: project : requirements <warnings>pedantic <warnings-as-errors>on ; Further down I have a dependency on BoostFilesystem like: run test_stdio.cpp : : : <library>/boost/filesystem//boost_filesystem ; But now the build of BoostFilesystem fails: gcc.compile.c++ bin.v2/libs/filesystem/build/gcc-5.4.0/release/cxxstd-11-iso/threading-multi/visibility-hidden/directory.o libs/filesystem/src/directory.cpp:217:48: error: unused parameter 'buffer' [-Werror=unused-parameter] Is there any way to restrict the warnings to my project only? Or at least the warnings-as-errors option? Is there a way to set warnings-as-errors via b2 command only for this library? This would avoid putting it in the Jamfile which could affect end-users, but having it on CI is actually enough. Alex

2 3

bug-fix release 1.72.1?
by Oliver Kowalke 15 Dec '19

15 Dec '19

Hello, unfortunately I accepted a faulty pull request and the commit that reverted it was not included into release 1.72 (for instance spawn() of Boost.Asio will fail to compile). Oliver

3 4

Assuming maintainership of boostorg/io
by Glen Fernandes 15 Dec '19

15 Dec '19

I'd like to take on maintainership of IO, as suggested by Peter. So far, I've already: * Implemented the Fundamentals TS v2 ostream_joiner as boost::io::ostream_joiner * Converted the documentation to Asciidoc * Updated the test cases to use Lightweight Test and build faster * Updated the CI configurations I also plan to: * Finish the boost::io::quoted implementation started by Beman but currently in detail. i.e. Update and improve the implementation. Add better documentation and more tests, and make it non-detail (public). * Migrate my boost::ostream_string facility from Boost.Utility (which is more general purpose) to Boost.IO (because, well, IO). * Make some minor improvements to the implementation of boost::io::ios_state. Glen

2 1

Re: [boost] Assuming maintainership of boostorg/io
by Bjorn Reese 14 Dec '19

14 Dec '19

On 2019-12-14 17:31, Glen Fernandes via Boost wrote: > I'd like to take on maintainership of IO, as suggested by Peter. +1

1 0

Attn: Maintainer of boost/bind.hpp
by Niall Douglas 13 Dec '19

13 Dec '19

In boost/bind.hpp there is injection of a boost namespace contents into the global namespace: ```c++ #include <boost/bind/bind.hpp> #ifndef BOOST_BIND_NO_PLACEHOLDERS #if defined(BOOST_CLANG) # pragma clang diagnostic push # if __has_warning("-Wheader-hygiene") # pragma clang diagnostic ignored "-Wheader-hygiene" # endif #endif using namespace boost::placeholders; #if defined(BOOST_CLANG) # pragma clang diagnostic pop #endif #endif // #ifndef BOOST_BIND_NO_PLACEHOLDERS ``` The fact that Boost actually disables the relevant compiler warning makes this particularly insidious. No modern C++ library should ever do "using namespace" into the global namespace in its public headers. Please fix this in the next release of Boost. Niall

2 4

Attn: Maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception
by Niall Douglas 13 Dec '19

13 Dec '19

Dear maintainers of Iterator, Python, ASIO, Detail, Core, Graph, QVM, Exception, Please find attached a list of macros in your libraries without BOOST_ prefixing, as is required by Boost library guidelines. If you could fix these promptly, it would be appreciated. Niall

1 1

Re: [boost] [release] Boost 1.72.0 has been released
by Glen Fernandes 12 Dec '19

12 Dec '19

Andrey wrote: > In release notes, New Libraries says TODO. Also on the main page it showed a blank list of updated libraries. Both should be fixed now: https://github.com/boostorg/website/commit/3f37b654d7126c0ad312e50d227c03d2… https://github.com/boostorg/website/commit/7c897e8c768cf28113ba07488a6b5030… Glen

2 1