September 2017 - Boost - lists.preview.boost.org

[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