- Boost - lists.boost.org

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[review] PolyCollection formal review results: ACCEPTED into Boost
by Ion Gaztañaga 23 May '17

23 May '17

Hi, Thank you for your participation in the PolyCollection review. I'll try to collect all votes and summarize the agreed changes on the library. ----- Votes ----- I count 8 (all positive) reviews and votes from Pete Bartlett Andrzej Krzemienski Hans Dembinski Thorsten Ottosen Vinnie Falco Edward Diener Brook Milligan Steven Watanabe -------- Comments -------- Additionally the following boosters did some positive comments on the library and made some questions Dominique Devienne Adam Wulkiewicz Myself No comment was blocking for the acceptance of the library so Boost.PolyCollection is accepted into Boost, congratulations to Joaquín! I recommend committing the library to the boostorg repo as soon as possible in order to start regressions and try to include the new library in Boost 1.65. Many of the proposed changes are one-liners in the documentation and code and hopefully will be ready for Boost 1.65. Deeper changes can wait until Boost 1.66. --------------------------------------- Summary of agreed comments and changes: --------------------------------------- ------------------ Dominique Devienne (positive comment) https://lists.boost.org/Archives/boost/2017/05/234672.php ------------------ "I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage" Joaquín will try to play with this idea to see how it fares performancewise. ------------------ Pete Bartlett (positive review) https://lists.boost.org/Archives/boost/2017/05/234669.php ------------------ "It may be worth remarking in the docs what facilities are used for the type registries that are presumably behind the scenes. From the reference section I think RTTI is required. Is this a hard limit or could Boost.TypeIndex be used?" Additional comment from the review manager: Consider making RTTI customizable. Boost.TypeInfo should be easily usable. In any case document the use of RTTI in the documentation. Joaquín will consider the customizable RTTI, will document that RTTI is required by the library. ------------------ Andrzej Krzemienski (positive review) https://lists.boost.org/Archives/boost/2017/05/234716.php ------------------ [1] "Based on my experience OO-inheritance solutions are faster that using `variant`. As you say below, I was suggesting the alternative design: `variant_collection`." Joaquín: "Some have asked for a variant_collection to be part of Boost.PolyCollection roadmap." [2] "I am not comfortable with per-segment functions having the same name as container-wide functions" Joaquín: "On the contrary, I like name overloading better, because it looks terser yet sufficiently expressive" [3] "I observed that the following small program crashes (assertion fails). According to the documentation this should throw an exception upon insertion rather than firing assertions" Joaquín: I think the assertion will be removed. [4] Commenting c.insert(x) / c.insert(it,x) reference: "And maybe it is just me, but I cannot make the sense of it" Joaquín: There is a typo that will be fixed. Will reword the reference sections into a more digestible form. ------------------ Ion Gaztañaga (positive comment) https://lists.boost.org/Archives/boost/2017/05/234729.php https://lists.boost.org/Archives/boost/2017/05/234745.php ------------------ [1] Model-based polymorphism: "Wouldn't be a good idea to make this model-based polymorphism (or a refined one) public? Maybe the current model needs more work to support additional polymorphism models." Joaquín: I'd be really conservative here and withhold such a big move until real use cases are found. The problem is once this is made public the design of the lib becomes effectively frozen. Will study it for the future if there's demand. [2] Optimize memory-indirection caused by unique_ptr: "segment_type could directly hold the class derived from segment_backend as packed_segment/split_segment will need the same size and alignment requirements regardless of the ConcreteType they hold (as long as they use std::vector). This could improve insertion times and other operations. This optimization could also make easier to fix the following section (allocator propagation)." Joaquín: In principle if the optimization is reasonably implemented t'd be welcome. [3] Allocator propagation: The library does not correctly propagate the allocator to support the scoped allocator model. Joaquín will fix this. [4] In many operations the dynamic type of the object to be inserted or manipulated can be known at compile, so the internal virtual call overhead can be optimized. Specially in "insert" and "emplace", but many other operations that work with a single segment can be optimized as well. Joaquín will review operations and will try to "staticfy" as much as possible. [5] Documentation should reflect some operations, like size<T>(), empty<T>() and others are not constant-time cheap operations. Thorsten suggested: The documentation should defin k = # of segments in container and add in those operations "Complexity: linear in k" as the explanation. Joaquín will document it. --------------- Adam Wulkiewicz (comment, but positive) https://lists.boost.org/Archives/boost/2017/05/234662.php --------------- [1] Polycollection doesn't meet the requirements of C++ container as defined in the standard, specially section (23.2.1.3). Joaquín: The part about 23.2.1.3 is not listed among the differences, will include it. --------------- Hans Dembinski (positive review) https://lists.boost.org/Archives/boost/2017/05/234694.php --------------- [1] "boost::function_collection was not so clear to me. It is nice to keep the narrative of game development going, but like someone said before, I think it would help to give a simpler example" Joaquín will improve the explanation [2] "I felt that the benefit of using boost::function_collection was not so clearly presented as for boost::base_collection. The function pointers are all the same size, so how exactly does the optimisation enter" Joaquín will improve the explanation. [3] "I tried to compile the tests on a Mac with Apple-clang 8.0.0. It worked after I manually specified "cxxflags=-std=c++11" Note from the review manager: No fix was discovered, I suggest working on this as many Apple users will have this problem. --------------- Thorsten Ottosen (positive review) https://lists.boost.org/Archives/boost/2017/05/234697.php --------------- [1] "OO programming and copyability of classes is not something that everybody is going to like. (...) Would it be possible for the library to pick up a private or protected copy-constructor when needed, possible via a friend declaration? (...) being able to have your hierarchy non-copyable while allowing copyability within the container is important IMO." Moveability is already required to store classes in the segment. Joaquín will study the possibility of using a copying traits class to let users customize this point. [2] "I miss range versions of the various iteration patterns so I can use them directly with a range-based for. E.g. instead of" Joaquín will implement it. [3] "Inside the segments you store std::vector. I could easily imagine the need to store something else, (...) Therefore I would love to have a second defaulted argument set to std::vector" Element contiguity is a key property and this customization requires a lot of work. Deferred for the future if there is demand for it. [4] "Implementation of equality: do we need to be set like semantics (two-pass)? Why don't you just delegate to the segments after checking the size?" Joaquín proposed a new slightly better implementation. [5] "tutorial: consider using override where appropriate" Joaquín will review code to use it. [6] "why ==,!= but not <,>,>=, <=" Joaquín followed the interface of std::unordered_set, [Review manager's comment: Consider explaining this in the documentation] [7] "Clarify that boost::poly_collection::for_each <warrior,juggernaut,goblin,std::string,window>( //restituted types c.begin(),c.end(),[&](const auto& x) loops over all elements or only the specific" Joaquín will clarify it. [8] "It could be good to have a performance test of erase in the middle/front." Joaquín will test it. [9] "using the identifier "concept" may require change in the near future?"s Joaquín will change it. [10] "I wouldn't mind seeing separate graphs for 0-300 elements." Joaquín will add it. [11] 2clarify test are without use of reserve" Joaquín will clarify it. [12] The test are testing best possible scenario; a more realistic test would be to copy pointers to an std::vector<base*>, shuffle it and run update on that. Joaquín will consider this, maybe additionally for 1-1000 elements. --------------- Vinnie Falco (Positive review) https://lists.boost.org/Archives/boost/2017/05/234704.php --------------- [1] "Iterators returned by begin<T>() produce a long, ugly compile error when compared against iterators returned by begin<U>() or end<U>()." Joaquín will study the issue. He's not sure if this can be improved. --------------- Edward Diener (positive review) https://lists.boost.org/Archives/boost/2017/05/234762.php --------------- [1] "It is also hard to understand what the advantage of a poly collection of these objects entail over a more normal C++ collection ( vector, array etc. ) of std::function<Signature> objects, since the latter object type already represents a generalized callable construct in C++." Joaquín will think about how to make the intro part more accessible. [2] "I have mentioned previously that I think the documentation should be more specific about the types being used for the boost::function_collection" Joaquín will take these points, and try to improve docs so as to make these aspects clearer. --------------- Brook Milligan (positive review) https://lists.boost.org/Archives/boost/2017/05/234872.php --------------- [1] "The only problem was that the following test cases needed -std=c++14 (rather than c++11) because std::make_unique is not defined for c++11 on that compiler: algorithms, basic_function, and segmented_structure. Perhaps a mention of the need for c++14 in some examples?" Joaquín will fix in the corresponding Jamfile.v2 and will mention it in the examples. --------------- Steven Watanabe (positive review) https://lists.boost.org/Archives/boost/2017/05/234877.php --------------- [1] Several documentation fixes Joaquín will apply recommended fixes [2] Change type_erasure::is_subconcept<type_erasure::assignable<>,Concept2>::value as Boost.TypeErasure was recently extended to support move assignment. [3] Fix "type_erasure::is_subconcept<type_erasure::typeid_<>,Concept>::value " with "typeid_<remove_cv_t<remove_reference_t<T>>> " [4] Fix "static void* subaddress(T& x){return boost::addressof(x);}" as it does not support multiple inheritance [5] Fix "return r(std::forward<Args>(args)...);" that does not correctly handle "void" return types. Joaquín will fix all of them [6] "make_index_sequence<N>" can be implemented more efficiently: Joaquín will find a better implementation. Review manager's comment: see https://stackoverflow.com/questions/17424477/implementation-c14-make-intege… [7] poly_collection is defined in namespace detail, internal functions can be found by ADL Joaquín will try to limit what ADL can find.

3 2

[config] Need help with clang config
by John Maddock 22 May '17

22 May '17

I've just added travis support to Boost.Config, the problem is that there are a large number of clang failures that I simply don't know how to fix, see: https://travis-ci.org/boostorg/config The errors occur because clang chokes on libstdc++ code, so while <regex> exists (for example), clang won't parse it. Any ideas anyone? Thanks in advance, John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 8

Re: [boost] Request for endorsements for mp11
by Bjorn Reese 22 May '17

22 May '17

I endorse mp11.

1 0

base64 ?
by Greger 22 May '17

22 May '17

Hi all, First: As an introduction: I am new on this list. Joined a few weeks ago. Second:is there any interest in base64? I have a library for encoding and decoding, which I could contribute. Thank you, tc Greger

6 7

Boost.Outcome and the C++ standard proposals
by Vicente J. Botet Escriba 20 May '17

20 May '17

Hi, for those that will follow the Boost.Outcome review I wanted to share some links related to the standard: The draft of the next revision : * D0323R2 -*A proposal to add a utility class to represent expected monad *(Revision 4) - https://github.com/viboes/std-make/blob/master/doc/proposal/expected/d0323r… The monadic interface draft proposal * DXXXX - *C++ Monadic inteface* - https://github.com/viboes/std-make/blob/master/doc/proposal/monads/Monads.md This is based on Hana customization in its pre-Boost version. And last a very draft paper I don't pretend to send to the standard meetings, at least not yet, about how FileSystem TS could be adapted to take in account the proposes status_value and expected classes. * DXXXX -*Refactoring FileSystem TS using **|expected|**or **|status_value|*||- https://github.com/viboes/std-make/blob/master/doc/proposal/expected/DXXXXR… This paper show that there is not silver bullet solution to reporting errors, but that making abstractions as status_value or expected makes the interface more clear, composable and readable (for me at least) than using out parameters error codes. The paper show also that wanting to have exception interfaces and non-exception interface forces to double the interface. Using expected could reduce it at the price of using .value(). I have an POC implementation in https://github.com/viboes/std-make/tree/master/include/experimental/fundame… Look for expected, functor, applicative, monad, monad_error folders for the implementation and std for the customization. My intention is to show that there is something on-going on the standard aside the expected proposal as requested by the committee. Note these drafts are of course not reviewed yet by the committee and I don't know if they will like the direction. We will see in Toronto next July Best, Vicente P.S. The dead line for next meeting is the 19 Jun. Any feedback is welcome, but as this is not C++ standard ML, I will prefer to have this feedback either privately or vi a the std-proposals ML.

2 1

[outcome] Changelog of all changes made since review announcement one week ago
by Niall Douglas 20 May '17

20 May '17

Dear list, The Outcome review begins later today, but so much feedback has landed this past week already that I had better announce what has changed in develop branch to prevent people reraising already fixed things: ## 20170519 boost_peer_review4: - Issue #13 The opcode counting CI tests in test/constexprs was severely broken on POSIX. Thanks to Tom Westerhout for finding the problem and supplying its fix. - unittests.cpp had become clang-tidy unclean, fixed. - Issue #15 Move `outcome::expected<T, E>` into `outcome::experimental::expected<T, E>`. Thanks to Vicente J. Botet Escriba for persuading me to do this. - Issue #14 Removed all the static asserts in the Expected implementation apart from the nothrow move constructor check, which is now correct unlike the incorrect assert from before. Thanks to Vicente J. Botet Escriba for explaining Expected's semantics. - Issue #21 Correct misspelling of `extended_error_code` with `error_code_extended` in the docs. Thanks to Deniz Bahadir for reporting this. - Issue #17 Give credit to Paul Bristow for the name "Outcome". Thanks to Peter Dimov for finding the correct person. - Issue #18 `result<T>` had a `.set_exception()` which it should not have had. Thanks to Peter Dimov for reporting this. - Issue #19 Remove observers `.is_ready()`, `.get_error_or()`, `.get_exception_or()`. Thanks to Peter Dimov and Andrzej Krzemienski for suggesting this. - Issue #20 Rename: - `monad_error` to `bad_outcome` - `monad_errc` to `bad_outcome_errc` - `monad_category` to `bad_outcome_category` - `BOOST_OUTCOME_THROW_MONAD_ERROR` to `BOOST_OUTCOME_THROW_BAD_OUTCOME` Thanks to Peter Dimov, Andrzej Krzemienski and Paul Bristow for suggesting this. If anyone prefers to see these changes in a tarball, you can get a tarball at https://github.com/ned14/boost.outcome/releases/tag/boost_peer_review4 or the boost_peer_review4 tag in git. Note that this tarball was generated straight off develop branch from my laptop and MAY NOT WORK well. I didn't get a chance to implement these outstanding issues before the review began: - https://github.com/ned14/boost.outcome/issues/11 Expected should never have a valueless state - https://github.com/ned14/boost.outcome/issues/12 Copy assignment gets instantiated even when type T cannot be copied - https://github.com/ned14/boost.outcome/issues/16 Default constructor of T is sometimes compiled when T has no default constructor Thanks in advance for your feedback and reviews. As I hope the above shows, it makes a big difference. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

[context] Windows x64 fiber local storage GS offset
by Elbert Mai 20 May '17

20 May '17

The Windows x64 implementation of Boost.Context saves fiber local storage from GS:[0x18]. For example, in jump_x86_64_ms_pe_masm.asm: ; load NT_TIB mov r10, gs:[030h] ; save fiber local storage mov rax, [r10+018h] mov [rsp+0b0h], rax However, this is the NT_TIB struct as defined in winnt.h typedef struct _NT_TIB { struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; PVOID StackBase; PVOID StackLimit; PVOID SubSystemTib; union { PVOID FiberData; DWORD Version; }; PVOID ArbitraryUserPointer; struct _NT_TIB *Self; } NT_TIB; This implies that fiber local storage is found in GS:[0x20], not GS:[0x18]. The Windows x86 implementation uses FS:[0x10], which is consistent with the NT_TIB struct. Am I missing something, or does Boost.Context save/restore fiber local storage at the wrong address in Windows x64?

3 3

[Beast] Discussion
by Vinnie Falco 20 May '17

20 May '17

A desire was stated in the 2015 formal review for Boost.Http, that the author would engage the community during the development of the library. I've been doing that throughout the development of Beast and I will continue to do so. So I am inviting you and anyone else who would like to participate in the design and evolution of this library to weigh in with comments on anything that you would like, ahead of the Beast formal review (scheduled July 1st). Your feedback can help make the library better! On Sat, May 20, 2017 at 8:19 AM, Bjorn Reese via Boost <boost(a)lists.boost.org> wrote: > On 05/20/2017 04:17 PM, Vinnie Falco via Boost wrote: > >> I hope readers are convinced that HTTP requests and responses should >> be modeled as self-contained objects with all necessary fields >> prescribed by rfc7230, and that the HTTP status should be neither >> separate nor stored in an error_code. > > > Not really, but that is the subject for a review of a different library. Here's a nice new thread for the discussion.

1 0

[math] Chebyshev polynomial
by Bjorn Reese 20 May '17

20 May '17

Does Boost.Math contain functions for Chebyshev polynomials? Preferably a recurrent chebyshev_next(). I can find functions for Legendre, Laguerre, and Hermite polynomials, but not Chebyshev.

3 3