May 2017 - Boost - lists.boost.org

Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
by Vicente J. Botet Escriba 30 May '17

30 May '17

Hi, I believe that this private mail I sent to Niall could concern the Boost community and the Outcome review. While the post concerns the proposed std::experimental::expected, this is applicable as well to Outcome. I've added a more points at the end and some additional information about possible open points for std expected. Le 24/05/2017 à 01:04, Vicente J. Botet Escriba a écrit : > > Hi, > > > After better understanding of the goals of Boost.Outcome I would like > to share two possible extension of std::experimental::expected > > > 1. Implicit conversion when the errors are convertible and the type is > the same. > > I believe this is a missing constructor. > > EXPLICIT expected<T, E>::expected(expected<T, G>); // E is > convertible from G > > I see that the other constructor is also useful > > EXPLICIT expected<T, E>::expected(expected<U, E>); // T is > convertible from U > > and so > > EXPLICIT expected<T, E>::expected(expected<U, G>); // T is > convertible from U and E is convertible from G > > We could as well have an adapt function that transforms expected error explicitly to do error propagation adapt : (E->G) x expected<T,E> -> expected<T,G> (E->G) stands for a function that takes an E and return a G. > 2. variadic expected<Y, E1, ..., En> > > I suggested this already in revision 2 of the Expected standard proposal. > > expected<Y, E1, ..., En> should be something like variant<Y, E1, ..., > En> but with some syntactic sugar. > > > expected<T, E1, ...., En> could be EXPLICIT convertible from > expected<T, G1, ...., Gm> as far as for all Gj we find a unique Ek > that is convertible to. > We can refine the subsumption relation this could take too long to the compiler (as the previous relation has quadratic complexity as Andrzej reported to me). > > I believe this will cover exactly what outcome covers and in addition > it will let open the error types used by the user. > > It acts as a exception specification, which we have abandoned in C++11. > > expected<T, E1, ...., En> f(); > > T f() throw (E1, ...., En); > > > We can consider that this is bad, as we have abandoned it. > > Anyway, I think that expected<T, E1, ...., En> is a good > generalization of the proposed outcome<T> where E1 could be none_t, E2 > could be error_code and E3 is exception_ptr. > > At the end users could use variant<E, E1, ..., En> are return code, so maybe we could to make their life easier. > > In this way we could have > > template <class T> > > using option = expected<T, nullopt_t>; > > Note that this is different to std::optional as the default is T not > nullopt_t :( > I'm not proposing it. Just to say that this could be a possibility for option. > > template <class T> > > using result = expected<T, error_code_extended>; // and possibly none. > > template <class T> > > using outcome = expected<T, none_t, error_code_extended, exception_ptr>; > > > I believe we would need the syntactic sugar as expected<T, > variant<E1,... En>> should have a lot of user code noise. > In addition it will be less efficient than variant<T, E1,... En>. > > E.g. expected<T, variant<E1,... En>> should be convertible from > unexpected_type<G> as soon a one of the Ek is convertible from G. > > I believe variant<E1,... En> is not convertible from variant<G1,... > Gm> under the conditions described above, but maybe this should be the > case. > Andrzej told to me that this is already the case for optional<T>, but I've not found yet on which paper this was added? > > Of course, the never empty warranties could be supported only if the > types Ek allow it and we need to change the standard to ensure it for > exception_ptr. > > > I will not have time to implement a POC for 2, but I believe I could > do it for 1 before Toronto. Anyway I believe it will be worth > discussing these 2 extensions. > > > Best, > > Vicente > > > P.S. EXPLICIT above has the sense given in the standard. > 3. uninitialized default constructed expected<T,E> I know this could be conflictual, but there are a some advantages to doing it. We don't spend time initializing with something we will assign later. This state corresponds to the moved-from state. Initializing it by default to T() is not better initializing to E(). Is expected<Date, error_code> default constructible even if Date is not? Currently it is not the case. There are of course liabilities. We have now the possibility for uninitialized variables, but static analysis tools will help here. 4. About comparisons Outcome doesn't implement comparisons between Outcomes. He pretend that we don't need them. In addition the mix of comparisons and implicit conversion give us some surprising cases as described in Andrzej blog. [1] A gotcha with Optional - https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional We have that std::future is not comparable (as exception_ptr is not comparable). Instead of comparison we could specialize std::less<> if we want to use them in ordered containers. What others think? 5. About implicit conversion from T The implicit conversion from T to expected<T,E> is a consequence of wanting that expected<T,E> should behave like a T. But this is not right. A expected<T,E> is not a T. We have in some way that expected<T,E> is explicitly constructible from E bu the use of make_unexpected(e). If we had only and explicit constructor from T the code will be much more uniform. Either you build it with a modified make_expected or with make_unexpected. In my opinion the implicit conversion from T to expected<T> is a mistake. 5. About the exception to throw std::experimental::expected throw bad_expected_access<E>. I adopted the design of optional and bad_optional_access We could have as well a bad_expected_access_base class as Outcome has. My question is why don't throw directly E? Some are requesting a way to get a specific exception from E, but either there is one exception that works for all and we can set it using some kind of trait or we need to add a trait parameter to expected to the the mapping :( Do we really want this to be configurable? 6. Implicit conversion from E outcome::expected<T,E> outcome::expected<T,E> is implicitly convertible from E when there is no risk of ambiguity. std::expected<T,E> is implicitly convertible from unexpected<E>. What people thing we should have? In Boost? in the standard? Vicente

5 21

[build] [config] check_target_builds and feature.subfeature composition
by Edward Diener 30 May '17

30 May '17

The Boost library config uses the check_target_builds rule to provide build time feature testing. Other Boost libraries use config checks in their own build and test jamfiles. I have found that this works reliably when a particular toolset is used in a normal manner. However when using the feature.subfeature and feature.compose rules to extend the toolset-version designation with a subfeature, such that the toolset designation now becomes toolset-version-subfeature, the use of the check_target_builds rule does not work as expected. In particular the individual check_target_builds rule results are put into a subdirectory based on the toolset-version and not based on the toolset-version-subfeature when toolset subfeature composition is used. I also suspect that the cached value reflects setup. This causes wrong results in tests where the toolset designation uses subfeatures, and a library's jamfile is using config and/or predef checks. As an example My toolset designation looks like: using gcc : 6.3 : some_path ; feature.subfeature toolset gcc : cxxstd : c03 c11 c14 c17 : optional composite propagated ; feature.compose <toolset-gcc:cxxstd>c03 : <cxxflags>-std=c++03 ; feature.compose <toolset-gcc:cxxstd>c11 : <cxxflags>-std=c++11 ; feature.compose <toolset-gcc:cxxstd>c14 : <cxxflags>-std=c++14 ; feature.compose <toolset-gcc:cxxstd>c17 : <cxxflags>-std=c++1z ; A library's test looks like: import ../../config/checks/config : requires ; run some_test.cpp : : : [ requires cxx11_hdr_forward_list ] ; If I run some some_test with toolset=gcc-6.3-c03, the config result for checking if forward list is supported is put into a subdirectory reflecting the toolset-version while the test result will be put into a subdirectory reflecting the toolset-version-subfeature. Subsequently if I run some_test with toolset=gcc-6.3-c11 the config result is taken from the subdirectory reflect the toolset-version even though whether the forward list is supported or not depends very much on the subfeature I am designating as part of the toolset. This naturally causes incorrect results for the test. Is this a known problem ? Is it a problem with Boost Build or is it a problem with how config uses the check_target_builds rule ? I have run into this problem extensively in my testing once I started to use the feature.subfeature ability of Boost Build.

5 9

[outcome] Review of Outcome
by Emil Dotchevski 29 May '17

29 May '17

I. Design There is a need in C++ for dealing with failures without using exceptions. This is not so much driven by actual inefficiencies (as opposed to perceived inefficiencies) of exception handling, but by the fact that not all C++ code in existence is exception-safe, and the fact that some C++ programmers work in environments where exception handling is disabled, as ill-advised such a decision may be. In my opinion the library should drop option<T> and result<T> altogether and should be reduced to outcome<T> only, which can be empty, or hold a T, or hold an exception (but not error code, see below.) This is critical for a library that aims to provide a _common_ general mechanism for dealing with failures in interfaces; providing a rich set of alternatives works against that goal. (It seems desirable to get rid of the empty state too but the discussions during the review period show that this might cause more problems than it solves.) Secondly, it is not a good idea to use error codes or any other value as means to dispatch on different kinds of failures because semantically such dispatch should be static: there is some _code_ which detects the error, and there is some other _code_ that needs to bind it and handle it. This is one reason why in C++ catch dispatches by the static type of the exception objects, not by some exception.what() value. Further, using static types to communicate different kinds of failures allows users to recognize and handle an entire class of errors by means of implicit type conversions, by organizing error types in a hierarchy. For example: struct io_error: virtual std::runtime_error { }; struct read_error: virtual io_error { }; struct write_error: virtual io_error { }; struct file_error: virtual io_error { }; struct file_read_error: virtual file_error, virtual read_error { }; struct parse_error: virtual std::runtime_error { }; struct syntax_error: virtual parse_error { }; With this hierarchy, we can use read_error to handle any kind of read errors (not just file-related), file_error to handle any kind of file failures (read or write), etc. That said, outcome<T> should also be able to transport values, however their purpose should not be to tell _what_ went wrong, but to provide additional information. It must be stressed that such additional information should be decoupled from the classification of the error. For example: outcome<parsed_data> parse_file( char const * file_name ); The above function reads a file and returns some parsed_data -or- stores an exception object in the outcome. What are the possible failures? It may be a file_read_error, but also types unrelated to I/O like std::bad_alloc or syntax_error. Regardless of the type of the failure, the outcome object should be able to transport the file name because it is relevant no matter _what_ went wrong. Incidentally, the need to transport contextual information independently of the error classification exists when throwing exceptions as well, so if outcome<T> can hold exception objects (and allow users to dispatch on their static type, like catch does), the exception objects themselves can take care of holding any additional information, for example by using Boost Exception. II. Implementation In general the library should not shy away from integrating with common Boost facilities in an effort to appeal to people who hate Boost. A Boost library should primarily target Boost users and address their concerns. This includes the testing framework as well as boost/config.hpp where applicable (it is okay to not always include boost/config.hpp, but it should be included to get things like BOOST_NO_EXCEPTIONS and other configuration macros.) The library should use BOOST_ASSERT, though I don't see a problem with not #including boost/assert.hpp if BOOST_ASSERT is already defined (by the user). The library should use BOOST_THROW_EXCEPTION to throw. Like in the case of BOOST_ASSERT, it's fine to not #include boost/throw_exception.hpp if BOOST_THROW_EXCEPTION is already defined. That said, avoiding coupling with individual Boost submodules is desirable in general. Also there is no problem with providing facilities to avoid all Boost coupling in order to support non-Boost users. III. Documentation The documentation makes broad claims about the inefficiency of exception handling which seem to be motivated by a desire to appeal to programmers who hold such beliefs. There is no need to make such generally untrue claims in order to justify the need for Outcome. Other than that the documentation does the job. IV. Verdict Should Outcome be accepted into Boost? NO This obviously applies only to the current state of the library.

3 4

[move] BOOST_RV_REF(TypeWithoutMoveEmulation) parameters
by Groke, Paul 29 May '17

29 May '17

Hi, I'd like to use BOOST_RV_REF, with both C++98 and C++11 compilers, for some sink-functions, with types that are not "move-enabled". I.e. types that the sink can "consume"/"move from" by other means (swapping, calling .release(), ...). Some of them I can - eventually - change to be fully move-enabled, others I can not (e.g. STL classes). I just assumed that this was possible by simply passing the argument with boost::move(arg). Apparently it's not though, because boost::move will return a plain T& for types without move emulation. For the time being I have defined my own helper function template "move_any" that will always return a rv<T>&. Is there such a function that I missed? And if not, would you think it'd make sense to provide one (I certainly think it would)? Regards, Paul Groke

3 5

[outcome] On the design and documentation
by Thomas Heller 29 May '17

29 May '17

Hi Niall (and also probably Vicente) I was following the discussion about expected/outcome/result very closely and I can absolutely see the usefulness of such a library (I explicitly discarded option here). I am not sure if this post should count as a review, mainly because I disagree with the fundamental design decisions (that includes expected as defined in D0323R2) and therefor would cast my vote as in "not ready yet", I hope I can convey my points below. First of all, I don't agree with the strong (conceptual) relationship between optional (be it boost:: or std::experimental) in such a way that expected is a generalization of it. From what I understand, the purpose of expected/outcome/ result is to be used as a mechanism to return the result of a function. As such it should also expose the semantics of it. Fortunately, we already have a (asynchronous) return object standardized (std::future). And this is my basic disagreement here: Why not model expected in the lines of future? With the main points being: - expected being movable only - expected<T,E>::value() should always return by value and invalidate this. - (I would really prefer the color .get though ;)) So the question to Vicente/Niall is: what is the motivation to make it "optional-ish"? Do we have use cases which make this design undesirable? By having these constraints, expected of course needs to have an uninitialized state. As such we'd have the three observers: valid(): true when has_value() || has_error(), false otherwise (for example default constructed, invalidated), has_value() and has_error(). Second, I think Niall raised a valid about outcome being a framework for interoperability (completely orthogonal to the first point). However, I totally miss this from the proposed library, most pressing are non intrusive mechanisms. For that purpose I postulate, that a mechanism to transform between different unexpected results, that is: various error codes etc. However, for that to work, one would of course need a properly defined concept, for example, as Vicente suggested "EitherValue", and a mechanism to coerce one error type into another, maybe through ADL, or traits specialization or whatever. With that in place, one could simply define the different EitherValue types, there is no need that everything needs to be in the form of "basic_XXX". For the library under review, this would be perfectly sufficient: template <typename T, typename E> class expected; template <typename T> using result = expected<T, extended_error_info>; template <typename T> using outcome = expected<T, variant<extended_error_info, exception_ptr>>; That is, given that we have either a value or unexpected, we can convert expected<T, E1> to expected<U, E2> if T is convertible to U and E1 "coercable" (with whichever mechanism) to E2. If we then have a generic mechanism to get from a (possibly user defined "E") to an exception, I completely miss the point of the outcome template. Furthermore, I believe that .value/.error should really have a narrow contract, that is that it is UB to call those functions if the respective types are not held (easy to catch this in a debug build...). Why? Probably just a micro optimization, but consider the canonical usage: auto r = some_function_returning_expected(...); if (r.has_value()) // Do something with the value else // An error occurred, PANIC In both branches, we know exactly what's in there ... so why check again when getting the state out? I don't get the "reinterpret_cast" argument. I am one of the persons that believe that UB is a necessary evil for some optimizations... All optimizations can then easily be put as implementation details and the generic expected<T, E> will probably suffice for most use cases, for everything else, we can implement special types which conform to our concepts and implement the error conversion mechanisms. This will most likely also work with different APIs/ABIs. Last but not least, I wanted to give some feedback on the proposed Boost.Outcome documentation. At the very least, I find it highly confusing. When I open its "landing page", I get no idea about the following: - What is the purpose of the library? - Why/when should I use it? - What should I look into next? >From the front page, it looks like a implementation of expected, but only talks about the outcome template, it is very hard to find the documentation for the other three types result, outcome and option. Yet, the documentation explicitly warns about it being unstable and suggests to use its refinements. Useful information is spread across the whole documentation, there is no easy way to find the requirements on T or E. The reference section is anything but complete and doesn't convey any useful information. I did not really look at the actual implementation of the proposed library. I cloned the git repository and had a quick glance, but to be honest, I got lost very early, I have no idea where to start looking first. Cheers, Thomas

6 15

[outcome] outcome without empty state?
by Andrzej Krzemienski 28 May '17

28 May '17

Niall, What do you think about the following alternate interface of outcome types? 1. Remove option<T> altogether. 2. result<T> (and outcome<T>) does not have a separate empty state. 3. A default-constructed result<T> is initialized as if `result<T>{error_code_extended{}}`. 4. Function r.empty() is implemented as `r.has_error() && !error()`. 5. Framework requires that type E in `expected<T, E>` is default-constructible, and its default-constructed value represents no error condition (already the case for exception_ptr, error_code). The rationale behind this is my assumption that `option<T>` is not as useful as the other types. (Or can you give an example to the contrary?) That there was no initial business need for an empty state, and the examples that illustrate its usefulness are just exploring how we can make use of it now that it is there. (Or am I wrong here?) I noticed a number of people report negative feedback about this empty state. Getting rid of it would take result<T> closer to "either T or reason for failure". What do you think? Regards, &rzej;

6 27

[review] Review of Outcome (starts Fri-19-May)
by charleyb123 . 28 May '17

28 May '17

Hi Everyone, The formal review of Niall Douglas' Outcome library starts today (Fri-19-May) and continues until Sun-28-May. Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/download/ boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - 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 what compiler? 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? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

17 70

[review] Review of Outcome (ends Sun-28-May)
by charleyb123 . 27 May '17

27 May '17

Hi, Everyone, First a (very-)big "thank-you!" to all participating in the ongoing (and vigorous) debate and review for the Outcome library. The spirited discussion touches on tricky issues for composition and error handling (with and without C++ exceptions enabled), where the community is clearly searching for best convention and common ground. Thus far: (a)- some 300+ emails discussing Outcome (and more emails off-list) (b)- participation from: *- Andrzej Krzemienski *- D25fe0be *- Deniz Bahadir *- Emil Dotchevski *- Gavin Lambert *- Glen Fernandes *- Gottlob Frege (Tony) *- Hartmut Kaiser *- Ion Gaztanaga *- Jonathan Muller *- Niall Douglas *- Paul Bristow *- Pete Bartlett *- Peter Dimov *- Robert Ramey *- Thomas Heller *- Vicente J. Botet Escriba *- Vinnie Falco *- ...(apologies if I've missed anyone) (c)- Some points-of-discussion relate to: *- Outcome efficiency (copy/move) on today’s compilers *- Outcome speed/overhead (exceptions) *- Outcome purpose/motivation *- Outcome Tutorials, documentation *- Outcome “formal-empty-state”, default-initialization *- Outcome compiling, compiler support *- Outcome ABI, namespace usage, use of preprocessor *- Outcome alternative APIs *- std::expected proposal, possible changes (d)- Reviews to date (sent publicly to the list): *- Paul Bristow -- accept, conditional (Tue-23-May) *- Deniz Bahadir -- accept, unconditional (Wed-24-May) *- Thomas Heller -- (almost a review), ?reject, "not-ready-yet?" (Wed-24-May) (e)- Significant other discussion also contributes to evaluation of Outcome as a Boost library. However, I encourage further reviews to make clear any conclusions from these discussions that I might have missed. The review continues for several more days, ending Sun-28-May. Please consider posting a review to the boost mailing list, or privately to the Review Manager (to me). Here are some questions you might want to answer in your review: - 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 what compiler? 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? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

8 16

Detail headers moved
by Belcourt, Kenneth 27 May '17

27 May '17

Hi, I’m trying to build Boost.Graph and running into missing header files that used to live in boost/detail and now live elsewhere. Here’s a couple of examples of headers that moved and the code that still expects to find them there: detail/container_fwd.hpp libs/functional/include/boost/functional/hash/extensions.hpp: #include <boost/detail/container_fwd.hpp> libs/lambda/include/boost/lambda/detail/operator_return_type_traits.hpp: #include "boost/detail/container_fwd.hpp" libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_list.hpp: #include <boost/detail/container_fwd.hpp> libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_map.hpp: #include <boost/detail/container_fwd.hpp> libs/phoenix/include/boost/phoenix/stl/algorithm/detail/is_std_set.hpp: #include <boost/detail/container_fwd.hpp> detail/indirect_traits.hpp libs/iterator/include/boost/iterator/detail/facade_iterator_category.hpp: #include <boost/detail/indirect_traits.hpp> libs/iterator/include/boost/iterator/indirect_iterator.hpp: #include <boost/detail/indirect_traits.hpp> It seems that indirect_traits.hpp was moved from detail into python/detail, and container_fwd.hpp into container. Just curious but was it intentional to make many Boost libraries depend on Python through boost/iterator/iterator_facade.hpp? Noel

2 4

[outcome] some problems compiling
by Andrzej Krzemienski 26 May '17

26 May '17

So, I am trying to run my first test program with Boost.Outcome. The library fails to compile with GCC 6.3.0 on MinGW on Windows 7. I have filed the issue: https://github.com/ned14/boost.outcome/issues/36 But also, I can see in file <boost/outcome/outcome_v1.0.hpp>, lines 1267 to 1279 ``` #ifdef __cplusplus namespace { #endif typedef struct _IMAGEHLP_LINE64 { unsigned long SizeOfStruct; void *Key; unsigned long LineNumber; wchar_t *FileName; unsigned long long int Address; } IMAGEHLP_LINE64, *PIMAGEHLP_LINE64; ``` 1. Why do you check for __cplusplus? Is it a copy-and-paste of some Windows headers? 2. This class and subsequent functions are defined in anonymous namespace. This means they are redefined and recompiled in each translation unit, and remain a per TU definition. Is that intent? Regards, &rzej;

5 11

Re: [boost] [outcome] Possible extensions/changes to std::experimental::expected
by Andrzej Krzemienski 26 May '17

26 May '17

It looks like part of the discussion accidentally went into a private conversation. So, here we are back. 2017-05-25 22:39 GMT+02:00 Vicente J. Botet Escriba < vicente.botet(a)wanadoo.fr>: > Le 25/05/2017 à 18:40, Andrzej Krzemienski a écrit : > > > > 2017-05-25 17:32 GMT+02:00 Vicente J. Botet Escriba < > vicente.botet(a)wanadoo.fr>: > >> Le 25/05/2017 à 13:18, Andrzej Krzemienski via Boost a écrit : >> >>> 2017-05-25 9:44 GMT+02:00 Vicente J. Botet Escriba via Boost < >>> boost(a)lists.boost.org>: >>> >>> We have now the possibility for uninitialized variables, but static >>> analysis tools will help here. >>> >>> So, more specifically, I understand that you propose the following: >>> >>> - Default constructor works: no T or no E is construced (similar what >>> outcome<> does) >>> >> I was not aware of this. Do you know that from this reference >> documentation? >> >> constexpr outcome () noexcept(is_nothrow_default_constructible) >> Default constructor. >> > > Well, I just assumed that since outcome<> has this empty state, it is > exactly for the purpose of giving semantics to the default constructor. But > now that you have asked, I looked at the docs. They say nothing about what > happens in the default constructor. I tried to look in the code, but was > confused with these policies. So, I just run a small test program, and yes: > default constructor creates an empty state. > > Niall, please could you add an issue in order to document default > constructors (if it doesn't already exists). > This is already logged in https://github.com/ned14/boost.outcome/issues/26 > > >> >> Sorrty, I couldn't interpret it as you. >> But, if it is the case, yes, as outcome does. >> >>> - You can assing to and and destroy such an objetc (similar what >>> outcome<> does) >>> >> I don't catch what you mean here. Are you referring to the conversion >> between expected with convertible value type and error types? >> > > No, I am saying that the following should work: > outcome<T> o; // default-constructed > o = some_outcome<T>(); // this should be safe to execute > > This works already with expected even if it doesn't defaults to empty. > Ok, and you expect it to continue to work. > > >> - You will probably need to add an observer function that checks for >>> this singular state, like `is_singular()`. If not for anything else >>> it >>> would be used for assisting the static analysis tools. (again, >>> similar what >>> outcome<> does) >>> >> No. There will be no such observer. This is essential. There is no >> visible empty state. >> Or do you consider that chrono::duration should tell you if it was >> initialized or not? >> The user know if it is initialized or not, but there is no tool to check >> it. >> This could be against safe programming, but we are here in C++ and we >> should provide first the raw tools and then build on top of them when we >> want more. >> >>> - other observer functions (has_value(), value(), has_error(), >>> error()) >>> cause UB when `is_singular() == true. (this is the only difference >>> from >>> outcome<>) >>> >> Not the only one. >> outcome fixes its error types. I'm proposing an extension to the current >> expected so that it can take care of the Outcome use cases and needs. >> >>> >>> Did I understand your intentions correctly? >>> >> Not completly. I don't want an observer that tells me, attention you have >> not initialized your variable, or you have moved from. This is essential. > > > Very daring. It would be easier to accept if you could show a tool that is > capable of statically analying this kind of "used unintialized" bug for > `expected`. > > > Static analysis to check if uninitialized variables are used (read) works > very well already . I don't remember if it si with clang-tidy that I have > seen this kind of warnings. > Ok. Now I am thinking, another thing you can do, is to internally store something like varient<T, Y, Empty> but do not expose this Empty in the interface. Instead, rewrite observer functions like this: ``` bool has_value() const { if (BOOST_UNLIKELY(_is_in_empty_state())) __builtin_unreachable(); return _is_in_valued_state; } ```

3 12

[outcome] expected<T&>, result<T&>
by Andrzej Krzemienski 26 May '17

26 May '17

Niall, Are Boost.Outcome monads intended to work with references (at least lvalue references)? If I try to compile the following program that tries to use an `result<T&>` (on GCC 6.3.1): ``` #include <boost/outcome.hpp> namespace out = BOOST_OUTCOME_V1_NAMESPACE; int g_count = 0; out::result<int&> get_ref() { return out::result<int&>(g_count); } int main () {} ``` I get lots of compiler errors. But the messages ("constructor cannot be overloaded") indicate that it was just an omission and not a design decision. If I try it with `outcome::expected` I also get these messages, but I also get a static assert saying that as per LWG decision T must be default constructible. Vicente, does this mean you cannot use `std::expected` to return references? Regards, &rzej;

5 8

Re: [boost] [outcome] expected vs. result
by Niall Douglas 25 May '17

25 May '17

> It would be very helpful to have a documentation for comparing all types, > expected, option, outcome, and result, showing the use cases and best > practices. I have some hard time to understand what one can do and the > other can not and in which cases I should prefer one. One thing very obvious in this review so far is how overwraught it has made that choice seem. I think as soon as you start writing some code using Outcome, you'll find the choice flows naturally. Using this library in your code is far, far, far easier and more intuitive than this review makes it seem. They are very simple objects, and very easy to use. Often the simpler the object, the more bikeshedding and strong opinions and noise result. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

3 2

[outcome] Ternary logic -- need an example
by Andrzej Krzemienski 25 May '17

25 May '17

Niall Douglas wrote: > Finally, if you did have some special E value to mean empty, you would > have to write special checks for it in Outcome in order to give it the > stronger abort type semantics it has - if you don't have it being given > alternative semantics, then there is no point in having an empty state. > If you are writing special checks, then you might as well just have a > formal empty state in the first place. > > This argument can be generalised into the argument in favour of ternary > logics over binary logics. Sure, 90% of the time binary logics are > sufficient, but binary is a subset of ternary. And *you don't have to > use* the "other" state in a ternary logic just because it's there. Just > don't use it, so long as its implementation signals its unintentional > usage with a very loud bang, it's a safe design. > > (There is an argument that Outcome's "very loud bang" isn't loud enough. > I'd be pleased to hear feedback on that) Niall, you mention "ternary logic" here, and I guess it has to do with 'module' `tribool` exposed by Outcome library. But I do not believe I have seen in the documentation (I mean the tutorial section) how I am supposed to use it, and how it improves my programs. Or I might have just missed it. Could you give me an example? Regards, &rzej;

7 46

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

25 May '17

Andrzej, Thanks for attempting to additionally clarify what you said before. > Again, sorry to reply on behalf of Niall, but it is my description that > might have caused the confusion. I'm glad you try to answer my questions as I know I will not get any from Niall directly. > There is still this case where you want to avoid exceptions in one part of > the program, but still use exceptions in other parts of the program. For > one example. in one "task" you launch another task with a callback > function `f`. You might want to throw from `f` and this is valid. But the > framework for launching tasks cannot afford to spill exceptions, so they > have to catch and somehow transport the exception (e.g., by exception_ptr) > then in the other task, you might want to re-convert to an exception. > (something similar to what std::future does.) I understand what you're saying, std::future needs a (conceptual) variant<T, exception_ptr> to store its state. So if I hear you correctly, outcome::expected<T, exception_ptr> could be used for that. > Other situation, is when you are using a third-party library, which throws > exceptions. You want to wrap it into a component that does not throw. > Boost.Outcome also supports in a convenient way this transition from and > to exceptions. Ok. > Also, maybe you will find of use the following example that tries to > illustrate the basic use case of the library: <snipped code example> 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>? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 3

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