September 2017 - Boost - lists.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 200

[yap] Re-announcing Yap
by Zach Laine 23 Feb '18

23 Feb '18

I posted 2-3 months ago about Yap, an expression template library I've written that I intend to propose for Boost. This is just a reminder that the library exists, and where to find it. I'm giving a talk about it at C++Now 2017, and some time after that I intend to submit it to the queue. Louis Dionne has offered to serve as review manager when the time comes. You can find the main repo on GitHub: https://github.com/tzlaine/yap And online docs are here: https://tzlaine.github.io/yap Zach

4 6

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

fuzzing boost at OSS-Fuzz
by Kostya Serebryany 31 Oct '17

31 Oct '17

Hi, I would like to invite boost developers to use OSS-Fuzz, a continuous automated fuzzing service. https://github.com/google/oss-fuzz https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.ht… I've made the initial set up that fuzzes boost::regex and it found 8 bugs there, see https://svn.boost.org/trac10/ticket/12818#comment:7 3460 boost: Integer-overflow in boost::re_detail_NUMBER::basic_regex_parser... 3464 boost: Integer-overflow in boost::re_detail_NUMBER::perl_matcher... 3469 boost: ASSERT: jmp->type == syntax_element_jump 3471 boost: Stack-overflow in boost::re_detail_NUMBER::basic_regex_parser... 3472 boost: Stack-overflow in boost::re_detail_NUMBER::perl_matcher… 3478 boost: Stack-buffer-overflow in boost::re_detail_NUMBER::perl_matcher... 3479 boost: Null-dereference READ in boost::re_detail_NUMBER::basic_regex... Vinnie Falco pointed me to Jens Weller's blog post about fuzzing beast: https://www.meetingcpp.com/blog/items/fuzzing-beast.html . Jens used libFuzzer, which is one of the two fuzzing engines used by OSS-Fuzz. Adding a boost library to OSS-Fuzz will look very similar to this blog post. For those of you who are at CppCon this week: we can discuss this face to face. --kcc

1 1

[review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Thorsten Ottosen 31 Oct '17

31 Oct '17

Dear users and members of Boost, I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html

24 159

Asciidoc, an alternative for documentation
by Peter Dimov 12 Oct '17

12 Oct '17

I've been experimenting with Asciidoc-based documentation, using Boost.Assert as my guinea pig. The good thing about Asciidoc is that Github shows a preview and you can edit it directly on github.com. This is how the source looks there: https://github.com/boostorg/assert/blob/feature/asciidoc/doc/index.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/assert.adoc https://github.com/boostorg/assert/blob/feature/asciidoc/doc/current_functi… This is how the generated HTML documentation looks, using the default stylesheet, without any customizations on my part: https://rawgit.com/boostorg/assert/feature/asciidoc/doc/html/assert.html And this is how the generated PDF looks: http://pdimov.com/tmp/assert.pdf The tool that produces these is Asciidoctor, http://asciidoctor.org/ .

13 34

[ANN] Boost.UI - a new C++ GUI library
by Kolya Kosenko 10 Oct '17

10 Oct '17

Hello, Here is my C++ GUI library based on Boost, it - is cross-platform - uses native system-provided widgets - has STL-like and Boost-like API - compatible with other Boost libraries - supports modern C++11/14/17 features Currently supported modules: - Graphics - Widgets * Command widgets * Data input-output widgets + Date and time pickers + Strings container widgets + Text widgets * Informational widgets + Logging * Containers + Alerts + Notifications + Prompts - Layouts - Events - Audio - Coordinates - Localization - Thread support - Helpers Documentation (and "Hello, World!" application source code): https://kosenko.github.io/boost.ui/ Source code: https://github.com/kosenko/ui Beman's challenge: https://github.com/kosenko/ui/blob/master/example/cpp11/beman.cpp Re-implemented GUI examples from Bjarne Stroustrup's book: https://github.com/kosenko/ui/blob/master/example/cpp11/stroustrup.cpp Other examples: https://github.com/kosenko/ui/tree/master/example What do you think? Regards, Kolya Kosenko.

11 21

[contract] auto_..._error regression tests fail on C++1z
by Lorenzo Caminiti 04 Oct '17

04 Oct '17

Hello all, I asked this question on compl.c++ list as well, given this is more of a general C++1z question than a Boost question. However, this is making some Boost.Contract regression tests fail on C++1z compilers so I wanted to ask it here as well hoping to get some info more quickly... Following code prevents copies outside its friend function f: // File: 05.cpp struct x { x() {} private: x(x const&) {} x& operator=(x const&) { return *this; } friend x f(); }; x f() { return x(); } int main() { auto xx = f(); return 0; } Correctly it does not compile up to C++1y because main cannot access the copy operations: $ clang++ -std=c++1y 05.cpp 05.cpp:14:15: error: calling a private constructor of class 'x' auto xx = f(); ^ 05.cpp:5:5: note: declared private here x(x const&) {} ^ 1 error generated. However, it compiles on C++1z?! $ clang++ -std=c++1z 05.cpp # Not compiler errors?! Why... what changed in C++1z that makes the above compile? How can I prevent copying x outside its friend function f in C++1z? Thanks, --Lorenzo

6 7

[outcome v2] How important is it that an Expected implementation is also provided?
by Niall Douglas 04 Oct '17

04 Oct '17

Dear list, I know it's been a fair few months since any news on Outcome v2. Ordinarily I'd be speaking at CppCon happening right now, but I instead chose Jens' Meeting C++ in November where I'll be speaking on Expected. Outcome v2 has undergone its period of maturation since it was completely rewritten to reflect peer review feedback last May. The new consensus design has fared very well after being put under heavy production use these last few months, and I expect it to return here for a second review before the end of this year. Outcome v2 will also be appearing in the WG21 October mailing, watch out for: * P0762R0: Concerns about `expected<T, E>` from the Boost.Outcome peer review * P0779R0: Proposing `operator try()` Outcome v2 currently implements the not published yet D0323R3 Expected proposal as part of its test suite as a refinement of what boost-dev thought Expected ought to be instead of what it is (ahem!). We run it against the Expected reference test suite, and it passes. So here's the question before any second peer review. Should Outcome v2 provide: 1. No Expected implementation at all, not even under a different name. Not its place. 2. The Expected implementation which the consensus on boost-dev felt the WG21 Expected ought to be (this is the current situation, and no we don't call it `expected<T, E>`). 3. A closely conforming, but not exactly conforming [1], implementation of WG21 Expected. Options 2 and 3 can be combined. But be aware that Peter rolled together an even more conforming Expected implementation using his variant2 library. I had been assuming people would be better advised to use his likely exactly conforming implementation, rather than Outcome v2's not exactly conforming implementation. Less surprise. Thoughts? Niall [1]: Known differences from P0323R3 `expected<T, E>` in this implementation: - `T` and `E` cannot be the same type. - No variant storage is implemented (note that technically speaking, D0323R3 does not require variant storage). -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 5

Boost CMake update
by paul 04 Oct '17

04 Oct '17

Hi all, So I have been working at converting more of boost tests to cmake utilizing the BCM library, here: https://github.com/boost-cmake/boost/tree/1.64 This is a build of Boost 1.64, with a majority of the tests integrated. There is still much more work needed to update the tests, as there are some that still fail. Also, some of the libraries were skipped due to missing headers in the 1.64 tag. You can check the library yourself by running cmake: cd build mkdir build cmake .. cmake --build . --target check This will build all the tests. You can check the tests for one target with: cmake --build . --target check-boost_core Which will run the tests for just `boost_core`. This was all generated using scripts in https://github.com/pfultz2/boost-cmake I plan to update this to a newer version of boost. If anyone has fixes or changes they can send a PR or issue on either repos, and I will try to incorporate them in. Thanks, Paul .

8 35

[review] The review period of Boost.DoubleEnded has been extended with one week. Now ends 7th of October.
by Thorsten Ottosen 28 Sep '17

28 Sep '17

Dear users and members of Boost, People have been requesting extra time for the review of Boost.DoubleEnded. We therefore continue one week extra, so the final date will be October the 7th. kind regards Thorsten Original review announcement ------------------------------------------ I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Boost.DoubleEnded as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html -- Best regards, Thorsten Jørgen Ottosen, Ph.D. Director of Research +45 23308797 Dezide (www.dezide.com)

1 0

[admin] Turning on Issues tab on Github for Boost libraries
by Edward Diener 28 Sep '17

28 Sep '17

Can we not have some resolution from an administrator about turning on the Issues tab in Github for Boost libraries ? There are two 'admin' issues regarding this and, since it should be a quick job for an administrator to implement this, I would really prefer not to wait for a long time for this to get done. Just now I had a "bogus" PR for iostreams, which I rejected, and the explanation from the person who created the PR was that the PR was "created" because there was no Issue tab for the library and he was only trying to create an Issue to be looked at. There is absolutely no logical reason that I can think of why the Issue tab on Github cannot be turned on for Boost libraries, to benefit end-users.

3 3

Re: [boost] [ANN] Boost.UI - a new C++ GUI library
by Kolya Kosenko 28 Sep '17

28 Sep '17

On 09/28/2017 03:02 PM, Stefan Seefeld via Boost wrote: >> - uses native system-provided widgets > > what widgets do you consider "system-provided" ? What backends do you > bind to on the different platforms, and can those bindings be changed ? Native system-provided widgets means widgets from toolkits GTK+, Qt, Windows Controls, Cocoa etc. >> - compatible with other Boost libraries > > What does that mean ? Boost.Geometry and Boost.Polygon could be used with Boost.UI coordinates, Boost.Chrono - boost::ui::on_timeout() function, Boost.Date_Time library are used in date and time pickers etc. > I'd be interested in some high-level documentation explaining the basic > programming and execution model of the API. You can ask for implementation details here. Documentation explains only API. > For example, how are events > handled and how are they bound to particular actions ? Library subscribes to event handlers in native toolkit. When user press button, native event handler eventually calls Boost.UI event handler. > Are programs > inherently multi-threaded or single-threaded (e.g., does the main event > loop run in its own thread) ? There is main GUI thread and you should call GUI functions from other your own threads using boost::ui::call_async() function. Boost.UI library (like all other C++ GUI libraries) aren't thread safe because native toolkits are not thread safe. > Is your library mostly just a (thin) layer over existing > platform-specific GUI libraries, or does it reimplement a lot of the > logic itself ? Boost.UI is a rather thin layer with C++11/Boost support. > (And what is that cryptic "ui_main()" function ? :-) ) ui_main() function call required for GUI initialization, deinitialization, cleanup. It is required for underlying toolkits. Actually you can call some functions directly from main() function, but it is at your own risk. Regards, Kolya.

2 4

[1.65] [process] Library version outdated
by Andrey Semashev 28 Sep '17

28 Sep '17

Hi, It looks like something is broken in the release procedure, which resulted in all Boost 1.64.0, 1.65.0 and 1.65.1 to contain the same revision of Boost.Process 4075371cbe78dab8f43578c655747c831b554318 (you can see that by git tags). This revision is dated Wed Apr 5 11:32:27 2017, which is more like when 1.64.0 was being prepared. I know that 1.65 has long sailed, but can the release managers double check that this doesn't happen in 1.66? As a possible clue, on the local checkout I didn't have a head for the master branch for Boost.Process for some reason. I surely wasn't doing anythhing special with its repository, but maybe something happened on the remote side that caused this. I solved the problem locally by removing libs/process, .git/modules/process and running `git submodule update --init --recursive`.

3 3

[Pool] no maintainer, and should perhaps be deprecated?
by John Maddock 27 Sep '17

27 Sep '17

Moving this conversation to a new thread: >As an example of this: I recently proposed to add variadic move >construction for nodes to boost::pool (a trivial change). And even though >this has obvious advantages (and would get rid for C++11 capable compilers >of the use of M4 to generate the necessary code), this was received with: >file a PR, including tests (?) and change to documentation. Enough to put >me off, so I just changed it locally. Unfortunately the pool lib is not a good example - as previously stated it has no current maintainer - but as (probably) the last person to try and do some community maintenance on this library, the impression I came away with was that it needs rewriting. Actually more than that.... it probably needs redesigning if many more of the existing bug reports are to be fixed. I've actually said this on the list before, and suggested that Pool.2 might be a good candidate for as someone's first Boost library (since it's not too large), but so far no takers. There is possibly another issue: the performance of most std lib allocators has improved to the point that it's actually questionable whether using the pool lib has much real benefit (but this need quantifying so the cases where it does help are documented). Maybe that's what has put people off, or maybe it's just not sexy enough for anyone to take on, but I still hope that someone will.... Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 1

[multi_index] Taking advantage of C++17 auto template params to simplify key specification
by Joaquin M López Muñoz 27 Sep '17

27 Sep '17

Consider the following: struct element { int x; int f()const{return x;} }; int gf(const element& e){return e.x;} using container=multi_index_container< element, indexed_by< ordered_unique<member<element,int,&element::x>>, ordered_unique<const_mem_fun<element,int,&element::f>>, ordered_unique<global_fun<const element&,int,&gf>> > >; With the advent in C++17 of auto non-type template parameters, it is very easy to provide a boost::multi_index::key class template so that we can write: using container=multi_index_container< element, indexed_by< ordered_unique<key<&element::x>>, ordered_unique<key<&element::f>>, ordered_unique<key<&gf>> > >; (Example at http://coliru.stacked-crooked.com/a/5742c768cc093c03 ). Is there interest in adding this to Boost.MultiIndex? Comments on this or alternative syntaxes? Thank you, Joaquín M López Muñoz

5 9

Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Fletcher, John P 27 Sep '17

27 Sep '17

________________________________________ From: Thorsten Ottosen [tottosen(a)dezide.com] Sent: 26 September 2017 08:28 To: Fletcher, John P Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30 >> Hi Fletcher, >> >> On another topic, I have not seen in the documentation any discussion of models for what is going on. I am aware of Chris Okasaki's book "Purely Function Data Structures" (1998) and a lot of subsequent literature. Does this work relate at all to previous work? >I'm not familiar with that book. You should think of standard C++ >containers like std::vector and std::deque which models a sequence concept: I should have given a reference. Here is one. http://okasaki.blogspot.co.uk/2008/02/ten-years-of-purely-functional-data.h… This is the authors comments on 10 years from publication. If you put the title into google you will get lots of information. My point is that there is a strong theoretical basis in this area and one of the issues for me is how far this has been taken into account in this new work. I was not until recently familiar with the work. It has helped me a lot understand the underlying problems in this area and I want to know whether the author of the library has looked at it. There is nothing in the documentation that I have seen about the wider issues. John Fletcher

2 1

Please fix executable permissions on header files
by Jonathan Wakely 25 Sep '17

25 Sep '17

The following files have executable permission bits set, which causes warnings for me when packaging Boost for Fedora (and is just wrong, because they're not executables): $ find boost_1_65_1/boost -name '*.hpp' -perm /111 boost_1_65_1/boost/numeric/conversion/detail/old_numeric_cast.hpp boost_1_65_1/boost/python/converter/arg_to_python.hpp boost_1_65_1/boost/python/converter/context_result_converter.hpp boost_1_65_1/boost/python/converter/pytype_function.hpp boost_1_65_1/boost/python/converter/return_from_python.hpp boost_1_65_1/boost/python/detail/convertible.hpp boost_1_65_1/boost/python/detail/copy_ctor_mutates_rhs.hpp boost_1_65_1/boost/python/detail/def_helper_fwd.hpp boost_1_65_1/boost/python/detail/is_shared_ptr.hpp boost_1_65_1/boost/python/detail/is_wrapper.hpp boost_1_65_1/boost/python/detail/nullary_function_adaptor.hpp boost_1_65_1/boost/python/detail/prefix.hpp boost_1_65_1/boost/python/detail/python_type.hpp boost_1_65_1/boost/python/detail/sfinae.hpp boost_1_65_1/boost/python/detail/unwind_type.hpp boost_1_65_1/boost/python/detail/unwrap_type_id.hpp boost_1_65_1/boost/python/detail/unwrap_wrapper.hpp boost_1_65_1/boost/python/detail/value_arg.hpp boost_1_65_1/boost/python/object/function_doc_signature.hpp boost_1_65_1/boost/python/object/inheritance_query.hpp boost_1_65_1/boost/python/object/stl_iterator_core.hpp boost_1_65_1/boost/python/arg_from_python.hpp boost_1_65_1/boost/python/base_type_traits.hpp boost_1_65_1/boost/python/borrowed.hpp boost_1_65_1/boost/python/cast.hpp boost_1_65_1/boost/python/def_visitor.hpp boost_1_65_1/boost/python/docstring_options.hpp boost_1_65_1/boost/python/handle_fwd.hpp boost_1_65_1/boost/python/object.hpp boost_1_65_1/boost/python/object_protocol_core.hpp boost_1_65_1/boost/python/raw_function.hpp boost_1_65_1/boost/python/refcount.hpp boost_1_65_1/boost/python/self.hpp boost_1_65_1/boost/python/stl_iterator.hpp boost_1_65_1/boost/python/wrapper.hpp boost_1_65_1/boost/interprocess/detail/managed_memory_impl.hpp boost_1_65_1/boost/interprocess/detail/managed_multi_shared_memory.hpp boost_1_65_1/boost/interprocess/detail/managed_open_or_create_impl.hpp boost_1_65_1/boost/interprocess/detail/shared_dir_helpers.hpp boost_1_65_1/boost/bimap/container_adaptor/unordered_associative_container_adaptor.hpp boost_1_65_1/boost/parameter/aux_/preprocessor/flatten.hpp boost_1_65_1/boost/parameter/aux_/preprocessor/for_each.hpp boost_1_65_1/boost/parameter/aux_/python/invoker_iterate.hpp boost_1_65_1/boost/parameter/aux_/overloads.hpp boost_1_65_1/boost/parameter/aux_/parameter_requirements.hpp boost_1_65_1/boost/parameter/aux_/result_of0.hpp boost_1_65_1/boost/parameter/aux_/tag.hpp boost_1_65_1/boost/parameter/aux_/template_keyword.hpp boost_1_65_1/boost/parameter/aux_/void.hpp boost_1_65_1/boost/parameter/aux_/yesno.hpp boost_1_65_1/boost/parameter/match.hpp boost_1_65_1/boost/parameter/parameters.hpp boost_1_65_1/boost/parameter/python.hpp boost_1_65_1/boost/parameter.hpp boost_1_65_1/boost/ptr_container/detail/default_deleter.hpp boost_1_65_1/boost/ptr_container/detail/is_convertible.hpp boost_1_65_1/boost/ptr_container/detail/move.hpp boost_1_65_1/boost/ptr_container/detail/scoped_deleter.hpp boost_1_65_1/boost/ptr_container/detail/throw_exception.hpp boost_1_65_1/boost/ptr_container/detail/void_ptr_iterator.hpp boost_1_65_1/boost/ptr_container/exception.hpp boost_1_65_1/boost/ptr_container/nullable.hpp boost_1_65_1/boost/thread/concurrent_queues/queue_base.hpp boost_1_65_1/boost/thread/experimental/parallel/v2/task_region.hpp boost_1_65_1/boost/thread/v2/shared_mutex.hpp boost_1_65_1/boost/iostreams/detail/adapter/device_adapter.hpp boost_1_65_1/boost/iostreams/detail/adapter/filter_adapter.hpp boost_1_65_1/boost/iostreams/detail/adapter/non_blocking_adapter.hpp boost_1_65_1/boost/iostreams/detail/broken_overload_resolution/forward.hpp boost_1_65_1/boost/iostreams/detail/config/enable_warnings.hpp boost_1_65_1/boost/iostreams/detail/config/limits.hpp boost_1_65_1/boost/iostreams/detail/config/windows_posix.hpp boost_1_65_1/boost/iostreams/detail/absolute_path.hpp boost_1_65_1/boost/iostreams/detail/bool_trait_def.hpp boost_1_65_1/boost/iostreams/detail/counted_array.hpp boost_1_65_1/boost/iostreams/detail/template_params.hpp boost_1_65_1/boost/iostreams/restrict.hpp boost_1_65_1/boost/msm/mpl_graph/mpl_graph.hpp boost_1_65_1/boost/typeof/dmc/typeof_impl.hpp boost_1_65_1/boost/typeof/std/bitset.hpp boost_1_65_1/boost/typeof/std/complex.hpp boost_1_65_1/boost/typeof/std/deque.hpp boost_1_65_1/boost/typeof/std/fstream.hpp boost_1_65_1/boost/typeof/std/functional.hpp boost_1_65_1/boost/typeof/std/iostream.hpp boost_1_65_1/boost/typeof/std/istream.hpp boost_1_65_1/boost/typeof/std/iterator.hpp boost_1_65_1/boost/typeof/std/list.hpp boost_1_65_1/boost/typeof/std/locale.hpp boost_1_65_1/boost/typeof/std/map.hpp boost_1_65_1/boost/typeof/std/memory.hpp boost_1_65_1/boost/typeof/std/ostream.hpp boost_1_65_1/boost/typeof/std/queue.hpp boost_1_65_1/boost/typeof/std/set.hpp boost_1_65_1/boost/typeof/std/sstream.hpp boost_1_65_1/boost/typeof/std/stack.hpp boost_1_65_1/boost/typeof/std/streambuf.hpp boost_1_65_1/boost/typeof/std/string.hpp boost_1_65_1/boost/typeof/std/utility.hpp boost_1_65_1/boost/typeof/std/valarray.hpp boost_1_65_1/boost/typeof/std/vector.hpp boost_1_65_1/boost/typeof/encode_decode.hpp boost_1_65_1/boost/typeof/encode_decode_params.hpp boost_1_65_1/boost/typeof/incr_registration_group.hpp boost_1_65_1/boost/typeof/int_encoding.hpp boost_1_65_1/boost/typeof/integral_template_param.hpp boost_1_65_1/boost/typeof/modifiers.hpp boost_1_65_1/boost/typeof/pointers_data_members.hpp boost_1_65_1/boost/typeof/register_mem_functions.hpp boost_1_65_1/boost/typeof/template_encoding.hpp boost_1_65_1/boost/typeof/template_template_param.hpp boost_1_65_1/boost/typeof/type_encoding.hpp boost_1_65_1/boost/typeof/type_template_param.hpp boost_1_65_1/boost/typeof/typeof_impl.hpp boost_1_65_1/boost/typeof/vector.hpp boost_1_65_1/boost/typeof/vector100.hpp boost_1_65_1/boost/typeof/vector150.hpp boost_1_65_1/boost/typeof/vector200.hpp boost_1_65_1/boost/typeof/vector50.hpp

5 7

request git repository for boost.contract
by Lorenzo Caminiti 25 Sep '17

25 Sep '17

Hello all, I need some help... who should I ask to create a git repository "contract" for boost.contract? How do I link that to the main boost repository in git? Please send me link if this info is already documented somewhere. Thank you. --Lorenzo

2 2

[review][Fit] Fit Review Results
by Matt Calabrese 25 Sep '17

25 Sep '17

Hello everyone, It is my privilege to announce that the Boost library count will once again be incremented as Paul Fultz II's library Fit has been accepted into Boost without conditions. Further details about this decision follow, but before that I'd like to thank Paul for all of the hard work he has put into Fit. Thanks also to everyone who participated in the review, with additional thanks to Vicente who was the review manager for the previous Fit review and who also provided a very detailed review and discussion during this review period. //////////////////////////////////////////////////////////////////////////////// Overview //////////////////////////////////////////////////////////////////////////////// Complete Reviews Considered: Zach Laine: Accept Vicente J. Botet Escriba: Accept John P. Fletcher: Accept Robert Ramey: Accept Jason Rice: Accept Barrett Adair: Accept Lee Clagett: Accept Glen Fernandes: Accept Louis Dionne: Accept Partial Reviews/Discussions Considered: Edward Diener Andrea Bocci Further Discussions (Previous Review): Steven Watanabe Peter Dimov Vladimir Batov Gavin Lambert Rob Stewart Bjorn Reese Manu Sanchez Artyom Beilis //////////////////////////////////////////////////////////////////////////////// Summary //////////////////////////////////////////////////////////////////////////////// Though not all responders reviewed every single aspect of the library, the reviews together adequately covered everything that is necessary for a decision to be made. This decision is made with additional confidence coming from usage of the library by some reviewers going back since during or before the initial review in early 2016. //////////////////////////////////////////////////////////////////////////////// Improvements Since Previous Review //////////////////////////////////////////////////////////////////////////////// This time around we received several more complete reviews than in the previous review period making it easier to be confident in a decision. A couple of notable changes since the 2016 review include: * Improved documentation * Default semantics for "capture" no longer try to determine whether to capture by reference or by value based on the argument being an lvalue or an rvalue (users can still get this via basic_capture) * Improved ADL awareness (internal calls are qualified) Throughout all of the discussions in this second review period, there were no explicit rejections of the library as a whole, though there were several recommendations from participants. A selection of those are listed here, though no changes are strictly required for acceptance: //////////////////////////////////////////////////////////////////////////////// Current Concerns //////////////////////////////////////////////////////////////////////////////// ////////// Design concerns: * Inheritance from user-callables has some potential pitfalls * Generated "infix" operators are "gimmicky" and don't add much value/may cause confusion * Placeholders should live in their own namespace ////////// Documentation concerns (not a complete list): * More examples requested * It is not always clear what files need to be #included for certain facilities in early examples * Better rationale for ConstFunctionObjects * Raw code is not linked from the examples ////////// Suggested name changes from reviewers: * Suggested rename of "partial()" to "partial_apply()" or "curry()" * Suggested rename of "conditional()" to "invoke_first()" or "call_first_of()" * Suggested rename of "apply" to "invoke" * Refer to "Callables" instead as "Invocables" (due to C++17 direction) * Library name "Fit" is not indicative of what it provides //////////////////////////////////////////////////////////////////////////////// Regarding the Author //////////////////////////////////////////////////////////////////////////////// Paul has been active in the Boost community for several years now. He is aware of his responsibilities going forward and I am confident that he will be a reliable maintainer for Fit for the foreseeable future (or whatever the library may be called). //////////////////////////////////////////////////////////////////////////////// Comments on the Name Boost.Fit //////////////////////////////////////////////////////////////////////////////// Note that what I say here is my personal opinion as a member of the community and does not necessarily reflect the opinions of others in the community nor of those in the steering committee. A few reviewers voiced that they would like to see a change of the library name "Fit". While multiple people did suggest this, my opinion is that this should be up to the author to choose whether or not he will change the name before it is added to boost and so I do not think it would be appropriate for us to strictly require or encourage such a change. If the author found the arguments against the name compelling, then he is welcome to change the name, but he should not feel obligated to do so. As a quick note on that, we have several high quality and highly regarded libraries in Boost with names that may not directly tell users what the library is for. Based on their popularity, I do not believe that it has significantly negatively affected their usage or ability to be found. A library name also may be important to an author as a creative outlet and I think it would be... poor form us to force such a change in this particular case and in other cases unless there are very strong reasons (i.e. the name is overly or intentionally misleading or there are legal concerns). I am not convinced that the current name is misleading enough to strictly require a change. As for existing precedent, some examples of libraries already in Boost with names that do not directly tell the user what the library is for include some of Boost's most highly regarded libraries such as Boost.Spirit (including Qi and Karma), Boost.Phoenix, Boost.Wave, Boost.Hana, and the recently accepted Boost.Beast. //////////////////////////////////////////////////////////////////////////////// Thanks again to everyone who participated in this review and in the previous review, and once again, congratulations to Paul on his library's acceptance into Boost. -- -Matt Calabrese

4 3

[utility] [config] value_init tests on msvc-14.0, 14.1
by Peter Dimov 24 Sep '17

24 Sep '17

Currently, value_init_workaround_test.cpp fails on both msvc-14.0 and 14.1, because in: #ifdef BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED // One or more failures are expected. return num_failures > 0 ? EXIT_SUCCESS : EXIT_FAILURE; #else // No failures are expected. return num_failures == 0 ? EXIT_SUCCESS : EXIT_FAILURE; #endif failures are supposedly expected (BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED is defined), but there are none. BOOST_DETAIL_VALUE_INIT_WORKAROUND_SUGGESTED is controlled by BOOST_NO_COMPLETE_VALUE_INITIALIZATION, which is defined on 14.0/14.1. The Config macro is defined because - presumably - msvc 14.0/14.1 fail the Config test for value initialization, boost_no_com_value_init.ipp. But this test is much more comprehensive than the value_init one. So to fix the value_init_workaround_test.cpp failure, we need to at minimum move one failing test case from the Config test to the value_init one.

2 3

Modular Packages on Conan.io
by Rene Rivera 24 Sep '17

24 Sep '17

One of the most requested feature from Boost users is having a "modular" distribution. I'm happy to announce that there are now modular packages available when using the Conan package manager from the Bincrafters team < http://bit.ly/2wM5AdT>[1]. Using the packages requires no prior setup other than the Conan tool. Immediately available are all 130 libraries from the 1.64.0 release. And in a few days we will follow up with the same for the 1.65.1 release. For help using the packages you can bug the Bincrafters team <http://bit.ly/2xWEGEX>[3] in the #conan cpplang.slack.com channel < http://bit.ly/2hnMB3o>[4]. Conan is a C/C++ (and more) package manager that supports an open ended set of build system and tool integrations including: VisualStudio, Xcode, CLion, Ninja, QMake, Premake, and yes even CMake <http://bit.ly/2xzhpbg>[2]. [1] <https://bincrafters.github.io/2017/09/22/boost-modular-packages-conan/> [2] <http://docs.conan.io/en/latest/integrations.html> [3] <https://bintray.com/bincrafters/public-conan> [4] <https://cpplang.slack.com/messages/C41CWV9HA> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 5

Including open source, non-copyright, no warranty in a boost library
by James E. King, III 24 Sep '17

24 Sep '17

Hello, I'm working on refactoring boost::uuids::name_generator to have a configurable hash algorithm through a template concept. RFC 4122 allows for two hashing algorithms, MD5 and SHA1. The current implementation only does SHA1, however I want to add MD5 for completeness (and I want to prepare for the eventual successor to SHA1 in the next RFC for UUID). I found an open source MD5 implementation of RFC 1321 at the following location and I was wondering if there are rules against bringing it into boost as a detail implementation? http://openwall.info/wiki/people/solar/software/public-domain-source-code/m… Thanks, Jim

4 3

BCM - Boost CMake Modules request for endorsement
by paul 22 Sep '17

22 Sep '17

Hi, So the Daniel Pfeifer has agreed to be the review manager for the Boost Cmake Modules. I would like ask for an endorsement so we can schedule a formal review for BCM. Thanks, Paul .

5 7

Travis/Appveyor improvements for the superproject
by Peter Dimov 22 Sep '17

22 Sep '17

Travis and Appveyor tests for the Boost superproject have been improved to automatically run the tests for the library mentioned in the commit message. For example, if the message is "Update iterator from develop", the corresponding CI job runs the tests of the Iterator library (among other things). This is a bit redundant if the library itself has Travis/Appveyor set up, but keeping an eye on https://ci.appveyor.com/project/boostorg/boost/history and https://travis-ci.org/boostorg/boost/builds can't hurt. For example, Appveyor says that Iterator fails a test on msvc-12.0 (Visual Studio 2013): https://ci.appveyor.com/project/boostorg/boost/build/1.0.3744-develop and Utility fails a test on msvc-14.0/msvc-14.1: https://ci.appveyor.com/project/boostorg/boost/build/1.0.3765-develop

9 16

[review][Fit] Review of Fit starts today : September 8 - September 17
by Matt Calabrese 22 Sep '17

22 Sep '17

A formal review of the Fit library developed by Paul Fultz II starts today, September 8, and runs through September 17. A branch has been made for the review. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Anyone who is able to provide an assessment of the design, implementation, and/or docs can participate in this review. Usage experience is not absolutely necessary to give feedback, but is highly recommended if you are writing a review. Discussions about aspects of the library are welcome even if a complete review is not presented, though participants are asked to please state whether they would like to accept or reject the library before the deadline of September 17, paying close attention to the questions raised at the end of this email. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. We will be grateful to receive a review based on whatever level of effort or time you can devote. This is the second time that Fit will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. The following is a brief description of the library from its author: ==================== Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming. Fit is: Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: Function Adaptors and Decorators: These enhance functions with additional capability. Functions: These return functions that achieve a specific purpose. Utilities: These are general utilities that are useful when defining or using functions. Requirements This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported. Contexpr support: Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION and FIT_STATIC_LAMBDA_FUNCTION constructs. Noexcept support: On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this. ==================== Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! -- -Matt Calabrese

13 39

Crypto/hashes library?
by James E. King, III 21 Sep '17

21 Sep '17

Hello, The boost uuid module contains an implementation of the sha1 hash algorithm for purposes of generating a uuid from arbitrary input. I've opened an issue on github to make the hash algorithm configurable: https://github.com/boostorg/uuid/issues/26 I was hoping to find a concept and implementation of a few hashes somewhere in boost that could be used instead, however I haven't found any. Back in 2010 someone posted a link to a "boost::hashes" repository but I was unable to see what the outcome of the discussion was other than that it was not included. A collection of hashing algorithms that are well tested would be quite useful in a number of ways; and I like the hash size template style used in the repo from 2010: https://svn.boost.org/svn/boost/sandbox/hash/ Indeed there's mention of a discussion about the proper placement of sha1 inside boost::uuid in there: https://svn.boost.org/svn/boost/sandbox/hash/libs/hash/doc/html/rationale.h… So I was curious where that effort ended up, and if there was a resolution on whether an independent library for hashing was ultimately something that folks wanted to pursue or avoid. Thanks, Jim

8 16

[move] [container] workaround for incorrect [-Wignored-attributes]
by Groke, Paul 21 Sep '17

21 Sep '17

Hi, we've stumbled over a supposed bug in GCC 6 that generates incorrect [-Wignored-attributes] warnings. Using anything in Boost that relies on boost::move_detail::aligned_storage (like boost::container::small_vector), with a small enough type, will trigger this warning when compiling for certain architectures with at least GCC 6.2~6.4. Affected architectures are e.g. SPARC and ARM - not affected are x86 and ARM64. GCC bug ticket: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82270 It would be possible to work around this issue by changing the implementation of boost::move_detail::aligned_storage_impl so that the aligned type no longer carries the attribute(aligned) itself, but just contains a member which carries that attribute. If I understand this correctly this should have the same effect (barring compiler bugs). Question: Would a pull request for such a change be welcome? Regards, Paul Groke

2 1

Mini review of the Fit library
by Glen Fernandes 21 Sep '17

21 Sep '17

What follows is my mini review of the Fit library. I had no time to write a full review, but feel that most of my points have been covered by others in both the first and this second review. A. Should the library be accepted into Boost? Yes; I vote to accept Fit - with no conditions for acceptance. B. What is your evaluation of the design? I found it: 1. Practical: For facilities like BOOST_FIT_LIFT. 2. Innovative: For facilities like infix(). And overall useful. C. What is your evaluation of the implementation? Good. Appears to be correct C++ code, and is definitely written in a very maintainable way. Ordinarily I'm in favor of not seeing macros used for what is accomplished by FIT_INHERIT_DEFAULT, FIT_INHERIT_CONSTRUCTOR, and similar, but this is a minor thing, and it does serve to make the code smaller and easier to review. I also like that the lowest version of C++ standard support required is C++11 (and not higher), as I am still aware of a large enough pre-C++14 user base that do have access to and use Boost libraries. D. What is your evaluation of the documentation? Excellent. Better than what I generally write. Useful enough for me, and in my opinion, sufficient for understanding the library and learning how to use it - for any user that takes the time to read through it all. E. What is your evaluation of the potential usefulness of the library? I believe it to be useful, and I know of at one developer that I have suggested Fit to, that has started using it - and another that would like to start using it if it is included in a Boost release (for which their organization has blanket approval to use). F. Did you try to use the library? With which compiler(s)? Did you have any problems? Not recently, but Yes. With g++ 6.3. I encountered no problems. G. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I had spent at least 3+ hours looking into Fit with the intention of reviewing it for my own use, and learning how one part of it was implemented. I did not have a chance to spend as much time as I would normally have to write a full review of the library. H. Are you knowledgeable about the problem domain? Familiar with enough functional programming design and generic programming to appreciate the library. Other notes: No concern about the name. We have Beast, Hana, Spirit; Fit is a fine enough name, and boost::fit:: is a convenient enough prefix. Glen

2 1

docs to release a new lib
by Lorenzo Caminiti 21 Sep '17

21 Sep '17

Hello all, Where are the latest docs to add a new lib to Boost (including regression tests, PDF docs, etc.)? Poking around a bit I found the following links... https://svn.boost.org/trac10/wiki/StartModMaint https://svn.boost.org/trac10/wiki/DeveloperChecklist I'm asking because I'm considering adding Boost.Contract to the Boost 1.66.0 release. Thanks a lot! --Lorenzo

1 0

[review] Final Notice! Fit Review Ends Today!
by Matt Calabrese 20 Sep '17

20 Sep '17

Hi everyone, The formal review of the Fit library is ending today, September 20th. For anyone who was waiting until the last minute to submit a review, this would be it. Anything that you can provide is helpful in making a decision, even if you do not write a complete review of the entire library. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! -- -Matt Calabrese

1 0

Re: [boost] [review][Fit] Review of Fit starts today
by Jason Rice 19 Sep '17

19 Sep '17

Please consider this review for the proposed Boost.Fit library. I recommend the review manager ACCEPT this library for inclusion in Boost without condition. # What is your evaluation of the design? - Making high order functions easier and more concise is a good idea. - I like the point-free programming features. - Some of the names, conventions, and errors would take any kind of user some getting used to. - A version of `alias_value` that works in a generic context where the type might not be an alias would be more useful I think. # What is your evaluation of the implementation? - The code is consistent across implementations and the files are pretty flat - Each function can be included independently which is nice. - It appears that there is some effort towards making errors easier to read. For instance, I called `fit::partial` with too many arguments and the error was "error: no member named 'fit_function_param_limit'" - There is some readability issues due to compiler compatibility support and specific compiler error workarounds. - I noticed `fit::decay` is not used in the tests at all. It gets included in `example.h` but is never used. # What is your evaluation of the documentation? - I like that the documentation is easy to read in the comments of each file. - Some of the wording in the descriptions weren't very helpful for me personally, but the "Semantics" section seemed to always get the point of the function across. # What is your evaluation of the potential usefulness of the library? - It seems parts of the library might not be that useful if you have constexpr lambdas, but I believe there are still features that enable more concise coding even against latest C++17 features. - I will probably use this library now that I am familiar with it. # Did you try to use the library? With which compiler(s)? Did you have any problems? - I made a couple of my own examples. - I used a fairly recent fork of clang trunk with c++1z. - BOOST_FIT_RETURNS *crashed the compiler* when I was trying to construct an std::array with some pack expansion. It looked like it crashed the parser. # How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - I spent a couple of hours looking at the docs in the source and making my own test programs to see how it could be used. # Are you knowledgeable about the problem domain? - I've used Boost.Hana a lot with its "functional" features. - I've done a lot of point free programming with RamdaJS in Javascript # Were the concerns from the March 2016 review of Fit addressed? N/A For what it's worth here is a link to some of my attempts to sample the library: https://gist.github.com/ricejasonf/9bfd233b3bc282eae9ecb8bc3198d948 Thank You, Jason Rice

2 1

[Container] small flat set ?
by Phil Endecott 18 Sep '17

18 Sep '17

Dear all, boost::container::small_vector and boost::container::static_vector are great. boost::container::flat_set is great too. But today I need a small_flat_set! And I don't think it's possible to compose flat_set and small_vector. (flat_set can use a custom allocator, but it can't take a custom implementation type in the way that, for example, std::priority_queue can.) Having said that, maybe composing flat_set and small_vector (or static_vector) isn't the optimum solution for the case where I will store something like 0...4 ints; I suspect that linear search in an unordered sequence will be quicker. But that gets complicated if you need iterators with the normal behaviour. Any thoughts? Regards, Phil.

5 14

Last Day for Boost Community Dinner Sign up
by Jon Kalb 18 Sep '17

18 Sep '17

Boost Developers, Today is the last day to register for the Boost Community Dinner at CppCon. http://sched.co/Bhcr You do not need to be registered to attend CppCon to register for the Boost Community Dinner: https://cppcon.org/registration/ If you are going to be in the Seattle area a week from Tuesday, join us for a rare face-to-face get together of the Boost Community. See you there. Jon

1 0

[docs] Documentation on Github?
by John Maddock 18 Sep '17

18 Sep '17

I notice that a few libraries are serving their documentation pages on github, for example http://boostorg.github.io/quickbook/doc/html/index.html How is this being done? Thanks! John. --- This email has been checked for viruses by AVG. http://www.avg.com

8 8

[review] Reminder that Fit Review Is Ending Soon. Please review!
by Matt Calabrese 16 Sep '17

16 Sep '17

Hi everyone, The formal review of the Fit library was scheduled to end tomorrow, September 17. At this point we do not have very many reviews and so we are extending the review period until the 20th. Anyone who can is encouraged to participate. Anything that you can provide is helpful in making a decision, even if you do not write a complete review of the entire library. You can find Fit for review at these links: Source: https://github.com/pfultz2/Fit/tree/boost Docs: http://pfultz2.github.io/Fit/doc/html/doc/ Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? - Were the concerns from the March 2016 review of Fit addressed? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Thank you for participating! - Matt Calabrese

1 0

[winapi] Enable Travis and AppVeyor
by Andrey Semashev 16 Sep '17

16 Sep '17

Hi, I'm trying to enable Travis and AppVeyor builds for Boost.WinAPI, and Travis says that I need admin rights on the project to do it: https://travis-ci.org/boostorg/winapi I don't know if AppVeyor also needs admin rights, maybe someone with more experience could clarify. Could I have the admin rights for Boost.WinAPI? Or maybe boostorg admins could do the necessary steps to enable the project in Travis and AppVeyor? Thanks.

2 7

Searching for Review Manager for reflection library without macro
by Antony Polukhin 15 Sep '17

15 Sep '17

Hello, PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Anyone wishing to become a Review Manager for the library? Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14 -- Best regards, Antony Polukhin

7 9

boost::random, header-only, boost::uuids::detail::seed_rng, and UWP development
by James E. King, III 14 Sep '17

14 Sep '17

Hi folks, It looks like the only reason boostorg/random is not a header-only library is due to random_device (it is the only src/ file: https://github.com/boostorg/random/tree/develop/src) The older WinCrypt calls are not available in some Windows platforms going forward, so this is going to become a problem pretty quickly for the community. In the boostorg/uuid library there is a seed_rng class which is doing similar things (however providing more entropy) and the library is header-only. In addition there are two filed defects - one in Trac and one in github issues, about uuid being incompatible with UWP applications (that's Windows universal apps). In uuid, I started adding support for BCrypt which is a Windows API supported on later versions of Windows, and once I changed my build flags to target Windows 10 and WINAPI_FAMILY_APP, I started getting build failures in random_device. On further inspection it looks like the random library doesn't have support for BCrypt yet, and even worse as a source library one would need to build two variants - one for WinCrypt and one for BCrypt to support older and newer windows platforms. There are also some implications on MinGW, as the older original MinGW has support for WinCrypt and MinGW-64 supports both. I'm going to propose that the implementation from boost::uuids::detail::seed_rng be moved into boost::random as the new random_device implementation. At the same time, boost::random will become header-only, and thus support setting _WIN32_WINNT at build time of consuming applications properly, and therefore support new Windows platforms properly. At the same time I would like to change seed_rng such that it no longer silently ignores some return values, and does not disable any compiler warnings (deprecations, currently). Thoughts? Thanks, - Jim

6 15

C++17 detection
by Robert Ramey 14 Sep '17

14 Sep '17

How do I get ready for C++17? I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have #if C++14 being used namespace std { // implement C++ function } // std I've looked in the documentation for Boost.Config and can't find any hints there. What is the best way to do this? Robert Ramey

14 25

[review queue] we seem to have double allocated early September for review --- what to do?
by Thorsten Ottosen 12 Sep '17

12 Sep '17

Hi All, I was about to announce the start of the Boost.Double_ended review, running from today to 17th of September. This is what we agreed upon with John (Phillips). Now, when I look at http://www.boost.org/community/review_schedule.html it seems that there is also a review of the Fit library scheduled, greatly overlapping with Boost.Double_ended. Do we run two reviews simultaneously, or what? kind regards Thorsten

5 12

Re: [boost] Review Request: impl_ptr (pimpl)
by Vladimir Batov 11 Sep '17

11 Sep '17

On 2017-08-19 23:55, Mario Lang wrote: > Vladimir Batov via Boost <boost(a)lists.boost.org> writes: > ... > I got interested enough by this posting so that I ended up doing my own > mini-review just right now :-). And I just wanted to let you know (and > encourage you) that I like this one alot. Keeping the public interface > free of boilerplate is quite nice! Mario, Thank you for your input. Much appreciated... although somewhat early. :-) It was pointed out to me that Boost review procedures changed and a proposal has to be endorsed before it can move to the review stage. So far I do not see it happening... maybe because the list is quiet (overall), maybe because iml_ptr is not good enough to attract that support/endorsement, maybe giving "endorsement" puts too much pressure and people shy away from it. We'll see. > I think for a full boost review, you will probably need to work on: > * The documentation > While I gave it a read, I ended up skipping to your test case because > I wanted to see working example code. > While the current docs have quite some examples, they spend a lot > more > screen space with showing what impl_ptr tries to replace, without > showing a good motivating positive example of how it actually looks > when employed. It also feels like it is spending some time with > marketing speak, while not really showing what it is trying to sell: Yes, I hear you... and I (at least partially) agree with you. First, no code or documentation will ever be to everyone's liking... unless everyone writes their own. Secondly, the documentation reflects many discussions we've had on this list about pimpl. For ex., I had to explicitly add what you call "marketing speak" to plainly explain why IMO pimpl is important. I had to address numerous "why bother" dismissing comments. What you call "marketing speak" I call an architectural view of a project. IMO it's quite different from developer's view that you seem to favor. All views are important... and all of them IMO need to be mentioned to cater for and to convince different readers. Surely, you (as a developer) is free to skip the "marketing speak". Somebody else (an architect and code-reviewer) might decide to skip other bits. No drama. Does it make sense? > The separation between the public interface in a hpp and the template > specialization in a cpp. I think the motivating example should > clearly show what part of the code goes where. Isn't what I did in third and fourth chapters? That said, I'll never be able to write the way you (or somebody else) like it. So, if you feel really strongly about it, please feel free to re-write it as you feel proper and submit. I am more than happy to consider and take others help. Unfortunately, that'll reverse our positions as I (and potential reviewers) might be saying "nuh, not enough "marketing speak" and such. No pressure... but that's an option to shape it up to your liking. > * Namespace: > While the alias is good, I think the whole code should be moved to > boost::, and the detail to boost::detail::impl_ptr::. > I am sort of guessing this will come up in the review. > I might be interested to help with that and submit the renaming PR if > you are open to that. 1) I do agree that the "whole code should be moved to boost::"... when it is part of Boost. Currently it is not. Currently I am on the earliest stage of gathering interest and waiting for "endorsement" and the review manager. 2) As I think I mentioned before impl_ptr is not part of any namespace by design... because the way proxy and implementation are connected, the specialization of impl_ptr<>::implementation. As I also mentioned it is IMO only a "problem" for "purists" but not for "practitioners" as from outside it is all kosher and accessed via boost::impl_ptr. You might be interested in searching for "Pimpl Again?" thread on this list for prev. discussions. Still, it you know a way around it and willing to submit your suggestions, I am certainly open for and most welcome it. But just to state the obvious -- as you do not like every line of code/doc that I write -- that goes both ways.

5 14

[beast] Post-review follow up (RE: chunk-encoding) NEEDS YOU!
by Vinnie Falco 11 Sep '17

11 Sep '17

During the formal review for Beast, a valid point was raised that the facilities for interacting with the chunks which make up a chunk-encoded was insufficient for some use-cases. I added more interfaces to addresses the use-cases but I never got feedback from the stakeholders about the design. It is now September 10th, and the "pencils down" deadline for making changes to Beast ahead of the 1.66.0 scheduled release is October 25th. As I have not gotten any feedback, I am asking the community if there is anyone out there who would like to review the new chunk-encoding facilities. As of yet, no one in the wild has used them. Or if they have, I did not hear of it. This is the documentation for the chunking: <http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_http/c…> Repository: <https://github.com/boostorg/beast> Any feedback is appreciated. Thanks

1 0

Fit review - viboes
by Vicente J. Botet Escriba 10 Sep '17

10 Sep '17

Hi, here it is my review. I believe that Boost.Fit should be*accepted*. *Design* The design is sound and clean. I have some concerns respect the the ConstFunctionObjects that I believe should merit an explanation on a rationale section. Why the library support only Const function objects? Wondering if some parts should be moved to Boost.TypeTraits or reused from there (is_callable). I'm missing the std::invoke function. The_adaptor<> are not documented. The utility of those classes is not documented. If the user can use those classes the documentaion must document them. I guess they are useful to build other adaptors. It is not clear whether the defined functions would use SFINAE or just fail when used with types that don't respect the requirements. While I'm generally for SFINAE, I understand that it will not be the case in order to improve the compile time. It is not clear if the functions can be final function objects or not. *Implementation* Not seen in depth. It should use as much as possible Boost.Config and/or Boost.Predef Possible files contains details that could be shared in Boost or used from other Boost libraries https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/constexp… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/intrinsi… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/pp.hpp https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/remove_r… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/result_o… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/static_c… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/using.hpp It uses a lot of macros that make complex the understanding of what is behind. On the same file https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/compose.hpp and only on 169 lines BOOST_FIT_INHERIT_CONSTRUCTOR, BOOST_FIT_RETURNS_CLASS, BOOST_FIT_SFINAE_RESULT, BOOST_FIT_MANGLE_CAST, BOOST_FIT_DECLARE_STATIC_VAR, BOOST_FIT_NOEXCEPT_CONSTRUCTIBLE, BOOST_FIT_ENABLE_IF_CONSTRUCTIBLE, BOOST_FIT_JOIN *Documentation* Quite good butthe description of the semantic of the provided functions would need some extra wording. Maybe a section that states that the semantic expression is part of the constraints on the types. It takes too much pages to see what the library proposes. For some functions we would need more information, examples. See below the detailed *Potential usefulness of the library* Very useful. *Did you try to use the library? With which compiler(s)? Did you have any problems?*** Not tried yet. *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?*** In-depth study of the documentation (about 5 h for this revision). *Are you knowledgeable about the problem domain?* In general, yes. *Were the concerns from the March 2016 review of Fit addressed?*** I believe ;-) Best, Vicente *Documentation:* In general: * Navigation only from the top of the page * Hyper links missing. * There is no link to real code from the examples. In particular: *http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html* An explanation of the BOOST_FIT_LIFT limitations would be more than welcome. Typo: last right parenthesis in // Pipable sum BOOST_FIT_STATIC_LAMBDA_FUNCTION(sum) = pipable([](auto x, auto y) { return x + y; }); It is not clear if the following is correct in the body of a function autosum = pipable([](auto x, auto y) { return x + y; }; *http://pfultz2.github.io/Fit/doc/html/doc/src/example_print.html* I would suggest to use an heterogeneous tuple in the for_each_tupleexample. In addition use some kind of brackets to print the sequences and the tuples would help to identify what is been printed. *http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html* Typo: Before // Check that T has member function for operator* and ope After // Check that T has member function for operator* and opeerator-> I'm not sure the example is_derreferenceable is fair. *http://pfultz2.github.io/Fit/doc/html/doc/src/example_polymorphic_constructors.html* Maybe it is worth adding references to the proposals (P0318R0 and P0338R2) *http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html* Extension Methods It is not clear what numbers, filter and transform are in the example. I believe that the range proposal woul include the pipe operator. My question is how both pipe operator overloads interact. http://pfultz2.github.io/Fit/doc/html/doc/src/point_free.html typo Before |b(f)(x, y)| |after| ||by(f)(x, y)|| *http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html* It woul dbe great to have an example associated to each definition Static Function Adaptor I would say "It has an additional requirement that the *class****function* is |DefaultConstructible|:" Decorator I would say "The *resulting* Function Adaptor <http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html#function-ada…> may be an unspecified or private type." Typo? Some parts of the documentation provides *http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html* ConstFunctionObject I would like to note that this concept is not representable using the Concept TS as it is quantifying universally on the Ts (args) parameters. The same applies to UnaryFunctionObject, BinaryFunctionObject Wondering if the documentation should use the term Concepts then. The use of expresion "Is an object with ..." is confusing. What are we qualifying the type or the instance? Maybe it is worth defining FunctionObject. EvaluatableFunctionObject It is not clear why this kind of FunctionObjects is useful Callable I believe we have moved to call this Invocable in the standard. But again, I believe that you want to quantify universally the arguments, isn't it? Does your definition of INVOKE differs from the one on the standard? If yes, the differences should be mentioned. If not, the definition on the standard should be referenced. You use type T twice with different meaning "The type |T| satisfies |Callable| if" "if |f| is a pointer to member function of class |T|:" I believe that here the T are not the same. Are final function objects Callable, ConstCallable? ConstCallable The brief description is the same as the one for Callable Is the definition of the second INVOKE different from the first one? UnaryCallable The name doesn't convey that it is *Const*Callable Metafunction and MetafunctionClass it is not clear what those are, there is no brief description. I guess that this applies to f. What do you mean by a type or a template? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/by.html* It is not clear to me what by(p)(xs...) == p(xs)... mean An example of `fit::by` without a function argument will be welcome. It is not clear how by_adaptor<Projection, F> and by_adaptor<Projection> can be used by the user? Shouldn't those be hidden? This is a genral remak, why F must be ConstCallable? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html *The requirements don't state clearly the constraints on the input parameters of f and the result of g, except by the semantic expression. This is a general remark. I suspect that you mean the semantic expression must be well formed. But, is this SFINAE friendly or is this a requirement? Can both function be final function objects? **** *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/conditional.html* It is not clear what king of parameters this function could have (in particular in comparison with P0051). Does it accept function/data members pointers, final classes, references_wrappers, ...? Typo "Proposal for C++ Proposal for" P0051 original proposal uses overload_linearly/overload (as Boost.Hana) instead of conditional/match. Wondering if those names aren't more clear. Why do we need to change the Boost.Hana names? There is also std::conditional :( Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/flip.html** * IIUC, F must not be BinaryCallable, but Callable with at least two arguments. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html* Is implicit a StaticFunctionAdaptor? Shouldn't StaticFunctionAdaptors have Functions as parameters? I named the `auto_cast` function `explicitly` to do a explicit conversion. Other uses of this pattern I've see are to create a buffer able to store a specific struct struct S; S* ptr = create_msg(); create_msg returns an class that is convertible to a T* and that allocates sizeof(T) bytes of memory. Why this pattern respect the DRY principle (we don't repeat S), I believe it abuses of implicit conversions. Anyway, I wanted just to share another use case for implicit. http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html Wondering if it could be worth adding some preconditions as I guess that the function call indirect(f)(xs...) will be undefined if f is null *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/infix.html** * One of the asked infix operations is pow. However we would like to evaluate from right to left and have the higher precedence than * x pow ypow z===pow(x, pow(y,z)) x * ypow z===x * pow(y,z) x pow y* z===pow(x,y) * zWith the proposed infix notation this should be written x <pow> (y<pow> z)===x * pow(y,z) x * (y<pow> z)===x * pow(y,z) (x <pow> y)* z===pow(x,y) * z and the following would be surprising x <pow> y<pow> z===pow(pow(x, y, z) x * y<pow> z===pow(x * y, z) x <pow> y*z===pow(x, y * z) It would work better for swap or compare (proposed operator <=>) as these functions are not associative. I believe a note should prevent the users for such bad use cases, for which it is better to don't define the infix operator. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lazy.html* Note p0356r1. It would be good to have a comparison in order either to improve the proposal or your library. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/match.html* Same comments than for fit::conditional. What are ex typo "Proposal for C++ Proposal for" Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html *Example of bad usage would be welcome.**Why Fit uses always const? **Why not use a reference to the function object instead? Is there a safe way to use MutableFunctionObjects with Fit? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/partial.html* Are there any constraints on the type of xs. Shouldn't them be MoveConstructibles? http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pipable.html Are there any constraints on the type of x. Shouldn't it be MoveConstructible? http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html It is not clear to me what this useful for. Could you elaborate? Is there a typo here assert(lazy(f)(protect(lazy(g)(_1)))() == f(lazy(g)(_1))) ^ Shouldn't it be assert(lazy(f)(protect(lazy(g)),_1)() == f(lazy(g)(_1))) *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html*** This adaptor converts explicitly the result of the call to the type. Have you considered `convert_to`? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html* as_failures, with_failures, .... /adaptors/ don't appear on the index. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reverse_fold.html* reverse_fold is not right fold, as right fold is right associative, isn't it? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/rotate.html*** Could you show a concrete use case? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html*** What are the differences of this adaptor and the macro STATIC_FUNCTION? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html* Why name it unpack instead of apply like in C++17? Need to introduce the Sequence concept and how it is customized? unpack_sequence? How unpack_sequence is used by unpack? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.html*** Why unpack_sequence, and not the tuple-like traits? Is unpack_sequence defined if the class defines the tuple-like traits? Aside the example, it is not defined what the user must define. What the member function apply must return? How the unpack_sequence parameter and the Sequence parameter of member function apply are related? I don't understand template<class F, class Sequence> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS ( s(std::forward<F>(f)) ); Is a Sequence a callable taking a Callable or there is a type here? Is there a missing return? I suspect it should be template<class F, class Sequence> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS ( std::forward<F>(f)(s0, ,, sk); ); If this is correct, does it means that unpack just forwards to unpack_sequence? Does the default specialization make use of INVOKE? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/capture.html*** Please, could you show how it is more flexible than lambda captures in C++? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/if.html* What happens when the parameter is false_type? SFINAE? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/limit.html*** if a function object is overloaded with 2 and 3 parameters, would limit be useful or it is only useful when the number of parameters is fixed? I believe this is answered in http://pfultz2.github.io/Fit/doc/html/doc/src/partialfunctions.html, however I believe it merits a clarification here. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html* Add requirement on the function parameter that must be a Unary function such that f(f(x)) is well formed. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat_while.html* The same here. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html*** What is the rational for the choice of been 1-based? Could you add a rationale in the doc? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/construct.html* Maybe add a reference to the factory proposal p03382. What happens when the parameter is not a T is not constructible from the params? SFINAE? What happens when the parameter is not a MetafunctionClass? SFINAE? I believe Boost.Hana uses make instead of construct. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html* Why not decay_copy? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/identity.html *is identity a function or a function object? do we need identity()(x)? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html*** Wondering if it is not better to locate them in a placeholders namespace, so that we can avoid possible collisions with other placeholders. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder* The same here *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function_param_limit.html*** |function_param_limit is not a Metafunction. "|The|function_param_limit| metafunction ..." *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/is_callable.html*** F must be Callable can not be a requirement ;-) Add reference to C++17 trait is_invocable. Wondering if we should have it in type_traits, if not already there. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html*** Confusion with std::apply. is this related to std::invoke? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function.html* "By default, all functions defined with|BOOST_FIT_STATIC_FUNCTION| use thereveal <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html> adaptor to improve error messages." How to change this default? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lift.html*** WhyBOOST_FIT_LIFT_CLASSdoesn't defines a instance as do BOOST_FIT_STATIC_FUNCTION? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pack.html*** How this is related with fit::capture? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html* How this is related to the tee unix command? *http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which ones?

2 3

How to deal with unused variable with a BOOST_ASSERT check?
by James E. King, III 10 Sep '17

10 Sep '17

In serialization (boost/archive/iterators/mb_from_wchar.hpp) there is some code that generates a warning on release builds. We're always striving for warning-free code in all cases. Here's the snippet: std::codecvt_base::result r = m_codecvt_facet.out( m_mbs, & value, & value + 1, wend, m_buffer, m_buffer + sizeof(m_buffer), bend ); BOOST_ASSERT(std::codecvt_base::ok == r); Normally I'd say one should always check the result and throw an exception instead of relying on an assert. I'm sure consumers would like that more. That said, is there another macro that would allow me to change the code to do something like this? BOOST_ASSERT_ASSIGN_OR_IGNORE(std::codecvt_base::result r) m_codecvt_facet.out( m_mbs, & value, & value + 1, wend, m_buffer, m_buffer + sizeof(m_buffer), bend ); BOOST_ASSERT(std::codecvt_base::ok == r); where BOOST_ASSERT_ASSIGN_OR_IGNORE would expand to, assuming BOOST_ASSERT_ACTIVE is an indicator whether assert code is compiled in: #if BOOST_ASSERT_ACTIVE std::codecvt_base::result r = #else (void) #endif This would allow me to eliminate the warning without submitting a PR that changes the behavior of the code. If something like this does not exist, would it be useful for me to add it to boostorg/assert, or would folks recommend against encouraging this behavior and instead change it to use exceptions? Thanks, Jim

5 4

range/concepts.hpp broken on master
by Peter Dimov 09 Sep '17

09 Sep '17

Trying to, f.ex., build quickbook on master fails with an error like ./boost/range/concepts.hpp: In destructor 'boost::range_detail::SinglePassIteratorConcept<Iterator>::~SinglePassIteratorConcept()': ./boost/range/concepts.hpp:167:55: error: 'iterator_traits' in namespace 'boost::detail' does not name a type That's because boost/iterator/iterator_concepts.hpp used to include boost/detail/iterator.hpp, and no longer does since this commit: https://github.com/boostorg/iterator/commit/0107df44ab3ab41c46b616c9c37c30f… This apparently works on develop, which means that it's probably fixed in Range's develop branch, but the changes aren't in master.

1 2

[build] using nvcc as toolset target?
by Oliver Kowalke 09 Sep '17

09 Sep '17

Hello, a grep over the boost.config showed some code related to nvcc - but I could not figure out how to use nvcc together with b2. What is the toolset target for nvcc ('b2 toolset=nvcc' doesn't work)? Oliver

2 2

Why is the boost documentation so bad?
by Florian Lindner 08 Sep '17

08 Sep '17

Hello, I really love to use boost libraries in my project, but I always wonder, for such an accomplished project, why is the documentation so bad? A few examples: I want to get familiar with http://www.boost.org/doc/libs/1_65_1/libs/ptr_container/. What do I need to include? Neiter the tutorial, the reference or the usage guidelines mention a #include line. This is something which stroke me quite often at various boost libs. Also with the ptr_container lib, I want to find the refrence for the ptr_vector::insert function. I got to scan the reference pages of all members of it's class hierarchy to find the insert() function (it's in ptr_sequence_adapter). References and example code often have no syntax highlightning and no linking and it's extremely hard to find documentation for a specific symbol, or from there, to jump to the source code. I would really like to have a more uniform and a documentation that not feels like a annotated source code dump. I use doxygen for my own projects and I know it can generate nicely looking, with syntax highlightning and linked documentation. Please, don't take this offensive, it's just some feedback I wanted to give a long time. Best, Florian

12 13