May 2017 - Boost - lists.boost.org

Re: [boost] Boost.Outcome review - First questions
by Hartmut Kaiser 25 May '17

25 May '17

Andrzej, > Thanks, I think I've seen this in the docs. All of this could have been > done with a variant<T, some_error_type> without changing the semantics, > yes? > > So I guess the next question I would like to ask is: what is the benefit > of using outcome::result<T> over std::optional<T>, and > outcome::expected<T, E> over std::variant<T, E>? > > At some conceptual level, yes, `outcome::expected<T, E>` is like > `variant<T, E>`. Two other types from this library could also be described > in terms of variant: > `outocome::result<T>` is like `variant<T, outcome::error_code_extended, > empty_state>` > `outocome::outcome<T>` is like `variant<T, outcome::error_code_extended, > std::exception_ptr, empty_state>` > Technically, you could use variant everywhere, but the tools from > Boost.Outcome offer an interface tailored to the use cases, loike > contextual conversion to bool. Also, a more focused scope than variant > offers room for optimizations. All of those could be equally well provided by a set of free-standing generic functions. There is no need to introduce yet another inventory type. As said elsewhere, a 'using expected<T, E> = variant<T, E>;' would do us the same in this case. > Having this `empty_state` is under debate. I hope at least the empty state gets dropped on the floor, even if I think the whole expected<> business is overkill and introducing a minimally necessary set of monadic helper functions (Vicente mentioned PossibleValue, MonadError, etc.) would be sufficient in many ways. With those functions a simple variant<T, E> would give us all we need. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

1 0

Boost.Outcome review - First questions
by Vicente J. Botet Escriba 25 May '17

25 May '17

Hi, I've tried to read the tutorial, but it is too long for my taste. I will try it later on :( A minor issue * "As inferred in the example code cases earlier, you can check if an |expected<T, E>| has an expected value via a simple test for boolean true or more explicitly via |.has_value()| before retrieving the value using |.value()|." This is not correct. It is correct for the de-reference operator, but .value() don't needs any check with .has_value(). Instead of some deviation, I would expect a report of all deviations and a rationale explaining why it is better to do this way. # "Types |T| and |E| cannot be constructible into one another. This is a fundamental design choice in basic_monad to significantly reduce compile times so it won't be fixed." * "Note though that |expected<void, void>| is permitted (which is legal in the LEWG proposal)." What are the compile time cost |associated the std::experimental::expected<T,E>? | I don't see what |expected<void, void> could mean. | # |unexpected_type<E>| is implemented as an |expected<void, E>| and it lets the basic_monad machinery do the implicit conversion to some |expected<T, E>| through the less representative to more representative conversion rules. Note that our Expected passes the LEWG Expected test suite just fine, so you probably won't notice this implementation detail in your code. The test of my POC implementation couldn't be complete, so this is not a sign of compatibility. Which operation allow to convert expected<void,E> to expected<T,E> and what is the expected behavior if expected<void,E> has a value? # Our |expected<T, E>| defaults E to |std::error_code| rather than |std::error_condition| (the LEWG proposal fixes this in P0323R2). I don't have a strong opinion on which default would be the best. As you suggested, I have added it to the next revision. We don't implement the ordering and hashing operator overloads due to https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/. The fact the LEWG proposal does as currently proposed is a defect (it will be discussed by LEWG with P0323R2 in Toronto). As for optional this could be considered a defect. The question is if we want expected to differen from the optional interface. If we considered it a defect, I don't believe that we should remove comparison, but IMHO we should make the constructor from T explicit. I don't expect the committee to fix this for expected and let the issue for optional. We will see. # We don't implement |make_expected_from_call()| as we think it highly likely to be removed from the next version of the proposal due to it conferring little value. This is possible and the function can be implemented very easily. I can live with and without it. # Our |make_expected()| and |make_unexpected()| functions deviate significantly as we believe the LEWG ones to be defective in various ways. This topic will be discussed in Toronto and reconciliation later is highly likely. Please, could you tell how those are defective so that we can fix them? Otherwise I don't see what we could discuss in Toronto. # Our |value_or()| member functions pass through the reference rather than returning by value (we don't understand why the LEWG proposal does except that |std::optional<T>| does, which itself is a bad design choice and it should be changed). Well, what is the advantage to returning by reference? Rather than |void|, our |value_type| and |error_type| typedefs are set to a descriptive compiler error generating type if the Expected is configured with |void|. If you want to know if no type was configured, use the static constexpr bools at |expected<T, E>::has_value_type| and |expected<T, E>::has_error_type| or use |raw_value_type| and |raw_error_type|. The reason for this deviation is to make metaprogramming using Outcome's transports much easier and less error prone. Sorry. I don't understand what is the issue. Could you elaborate? # Our Expected always defines the default, copy and move constructors even if the the type configured is not capable of it. That means |std::is_copy_constructible| etc returns true when they should return false. The reason why is again to significantly improve compile times by hugely reducing the number of templates which need to be instantiated during routine basic_monad usage, and again this won't be fixed. Instead use the static constexpr bools at: Defining these operation when they can not be implemented means that you cannot use SFINAE on this type. Maybe I'm wrong, but I believe we want to check if a type is constructible, ... using the C++ standard type traits. Next follow the first questions I have mainly from the reference documentation of expected<T,E>. In general I find most of the operation not specified enough. I would like to have something in line with the standard way of specifying an interface. * it is not clear from the reference documentation if expected<void,E> is valid? |* |is expected<T,E> the sum type of T, E and empty? and exception_ptr? |"outcome<T>| can be empty, or hold an instance of a type |T|, or hold an instance of |error_code_extended|, or hold an instance of |std::exception_ptr|. This saves you having to wrap an error code into an exception pointer instance, thus also avoiding a memory allocation." std::experimental::expected requires that its Error type to be no throw constructible, copyable and movable. What are the exception warranties for |error_code_extended? | What are the exception warranties for |outcome<T>||? | * inplace construction What is the difference between: constexpr expected (value_t _) noexcept(std::is_nothrow_default_constructible< value_type >::value) Implicit constructor of a valued monad (default constructed) and constexpr expected (in_place_t, Args &&... args) noexcept(std::is_nothrow_constructible< value_type, Arg, Args... >::value) when there is no Args. IMO the second subsumes the first and so there is no need fro the first overload and the value_t tag. * default constructor constexpr expected () noexcept(is_nothrow_default_constructible) Default constructor. This doesn't say what the default constructor does. * Shouldn't constexpr expected (in_place_t, std::initializer_list l) noexcept(std::is_nothrow_constructible< value_type, std::initializer_list>::value) Implicit constructor from an initializer list. be constexpr explicit expected(in_place_t, initializer_list il, Args&&... args); * What is void_rebound and where it is defined constexpr expected (const void_rebound &v) noexcept(std::is_nothrow_copy_constructible< error_type >::value) Implicit constructor from an identically configured basic_monad<void> by copy. * construction from error type What is wrong with template <class... Args> constexpr explicit expected(unexpect_t, Args&&...); template <class U, class... Args> constexpr explicit expected(unexpect_t, initializer_list, Args&&...); Why do you prefer an implicit conversion. This deviation must be in the rationale of the differences. constexpr expected (const error_type &v) noexcept(std::is_nothrow_copy_constructible< error_type >::value) Implicit constructor from a error_type by copy. constexpr expected (error_type &&v) noexcept(std::is_nothrow_move_constructible< error_type >::value) * raw types It is not clear what is the difference between xxx and raw_xxx typedef value_storage_type::value_type value_type The type potentially held by the monad. typedef implementation_policy::value_type raw_value_type The raw type potentially held by the monad. typedef value_storage_type::error_type error_type The error code potentially held by the monad. typedef implementation_policy::error_type raw_error_type The raw error code potentially held by the monad. typedef value_storage_type::exception_type exception_type The exception ptr potentially held by the monad. typedef implementation_policy::exception_type raw_exception_type The raw exception ptr potentially held by the monad. * What is the "The exception ptr potentially held by the monad"? * what is the sizeof expected <T,E>? * is basic_monad something proposed or an implementation detail? If the first, this should be renamed, if the second this class should not appear in the documentation and the word monad should be banned. * What is expected<Policy> in template<class Policy , typename = typename std::enable_if<std::is_same<typename implementation_policy::value_type, typename Policy::value_type>::value || std::is_void<typename Policy::value_type>::value || std::is_constructible<typename implementation_policy::value_type, typename Policy::value_type>::value>::type, typename = typename std::enable_if<std::is_same<typename implementation_policy::error_type, typename Policy::error_type>::value || std::is_constructible<typename implementation_policy::error_type, typename Policy::error_type>::value>::type, typename = typename std::enable_if<std::is_same<typename implementation_policy::exception_type, typename Policy::exception_type>::value || std::is_constructible<typename implementation_policy::exception_type, typename Policy::exception_type>::value>::type> constexpr expected (expected< Policy > &&o, explicit_conversion_from_different_policy=explicit_conversion_from_different_policy()) Explicit move constructor from a basic_monad with a differing implementation policy. For this constructor to be available, value_type, error_type and exception_type must be identical or constructible. * move constructor/copy constructor The reference documentation doesn't says what this does. * Missing move/copy assignment * bool conversion should be explicit * is_ready has nothing to be with expected. * Shouldn't value_or return by value? otherwise what would be the difference between get_or and value_or? * emplace. Missing overload template <class U, class... Args> void emplace(initializer_list, Args&&...); * swap: What is the meaning of swapping an expected with an option? swap must follow the standard signature. * Missing preconditions on the observers, which make them wide operations. Saying that they return an address makes them wide operations however accessing to the contents of this address will be undefined behavior. I prefer the standard way, defining a narrow function and stating clearly the pre-conditions. * what error_or <https://ned14.github.io/boost.outcome/structboost_1_1outcome_1_1v1__xxx_1_1…> returns if it contains an exception? * what is the difference between get_error_or and error_or? https://github.com/ned14/boost.outcome/issues/19 * Missing overload for get_unexpected. In addition it doesn't return an unexpected_type. constexpr const E & get_unexpected () const; Best, Vicente

12 63

boost.interprocess atomic uint64?
by dnj0496 24 May '17

24 May '17

Hi, I am looking at interprocess/detail/atomic.hpp file and all atomic operations seem to be dealing with uint32. Does boost interprocess not support uint64 types? Can it work similar to std::atomic<type>? Thanks. Dk. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-interprocess-atomic-uint64-tp46945… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[outcome] expected vs. result
by Andrzej Krzemienski 24 May '17

24 May '17

Niall, I am trying to summarize differences between `expected<T, error_code>` and `result<T>`. So far, I have identified the following: 1. API/ABI stability guarantees. 2. `result` has empty state - `expected` does not. 3. `result` uses error_code_extended for more error details in the ring-buffer. 4. No ordering (operator<) for `result` Is the above list complete? Regards, &rzej;

2 1

issue in using vector in version 1.64
by Rishabh Arora 24 May '17

24 May '17

Hello, I just build the latest version of boost (1.64) I tried running the following code: http://ideone.com/n6FSKr It didn't compile and instead gave the following error: https://usercontent.irccloud-cdn.com/file/Pf0b8F8L/Screenshot%20from%202017… Can someone please help in understanding and rectifying it. Thanks in advance, Best Regards, Rishabh

4 3

Request for endorsements for mp11
by Peter Dimov 24 May '17

24 May '17

Would anyone be so kind as to formally endorse mp11 as a candidate for Boost? As a reminder, mp11 is a simple C++11 metaprogramming library, available at https://github.com/pdimov/mp11/ CSS-less documentation can be viewed at https://rawgit.com/pdimov/mp11/master/doc/html/mp11.html

9 15

std::auto_ptr in public interfaces
by Daniela Engert 23 May '17

23 May '17

Hi everybody, you are probably aware of the fact that the upcoming C++17 standard is going to remove std:auto_ptr (and other deprecated features), and that MSVC 14.0 and 14.1 no longer supply these deprecated, to-be-removed features when compiling in a 'later than C++14' mode (i.e. /std::c++latest or /std:c++17). Today I've learned that latest versions of libc++ also no longer supply std::auto_ptr when compiled in C++17 mode. Some time ago I've talked about an in-house version of Boost which no longer requires these deprecated features and builds and passes tests in C++17 mode. As of yesterday I've completed my pull-requests against all those libraries using any of these features (¹), to deal with this situation where required - except for two libraries: locale and ptr_container. These two remaining libraries use std::auto_ptr in their public interfaces and replacing std::auto_ptr with std::unique_ptr is not as easy as a replacement of std::auto_ptr used in the bowels of a library or in test code. It would impose respective changes to user code as well. In our company we just got rid of all traces of std::auto_ptr and happily keep on using locale and ptr_container just as before. So guys, what's your opinion of how to deal with this situation? Ciao Dani ¹ algorithm, asio, assign, bimap, container, gil, graph, icl, interprocess, intrusive, lockfree, msm, phoenix, polygon, random, range, regex, statechart, test, typeof, wave, xpressive -- PGP/GPG: 2CCB 3ECB 0954 5CD3 B0DB 6AA0 BA03 56A1 2C4638C5

10 19

[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() or end()." 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