- Boost-users - lists.preview.boost.org

Compiling Boost 1.64.0 with Visual Studio 2017
by Leo Carreon 31 May '17

31 May '17

Hi, Has anyone tried building Boost 1.64.0 with Visual Studio 2017 in “/std:c++latest” mode? I’m asking because I tried and the build generated a lot of errors and some of them are to do with things that have been removed in C++17, e.g. std::auto_ptr, etc. It seems that these need to be resolved soon especially when a lot of the compilers become C++17 compliant. If anyone is curios, I’m attaching a ZIP file containing my complete build log. Kind regards, Leo

1 0

Boost.Python can't link using downloaded pre-compiled binaries
by Heng Zhou 30 May '17

30 May '17

Following are the environment: - Windows 7 Enterprise SP1 64 bit - Python 2.7.13 - Visual Studio 2015 (v14.0) Following are the steps to the problem: (1) I downloaded boost_1_64_0-msvc-14.0-64.exe from https://urldefense.proofpoint.com/v2/url?u=https-3A__sourceforge.net_projec… . Since it is pre-compiled binary, I think there is no need to build Boost.Python manually. Note that it is for 64 bit build in VS2015 if I understand correctly. (2) Install the pre-compiled binary to C:\local\boost_1_64_0 (3) Follow the Boost.Python's QuickStart here: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.boost.org_doc_libs_… . The source code are the same as shown therein. (4) Set in VS2015 Property Pages->C/C++->Additional Include Directories: C:\local\boost_1_64_0;C:\Python27\include Set in VS2015 Property Pages->Linker->Additional Library Directories: C:\local\boost_1_64_0\lib64-msvc-14.0;C:\Python27\libs Set in VS2015 Property Pages->Linker->Input->Additional Dependencies: boost_python-vc140-mt-1_64.lib;boost_python-vc140-mt-gd-1_64.lib;%(AdditionalDependencies) Set in VS2015 Property Pages->General->Configuration Type: Dynamic Library (.dll) (5) Build under x64 configuration and got errors: 1>Source.obj : error LNK2001: unresolved external symbol __imp_PyString_Type 1>Source.obj : error LNK2001: unresolved external symbol __imp__Py_NoneStruct 1>C:\...\ConsoleApplication1\x64\Release\ConsoleApplication1.dll : fatal error LNK1120: 2 unresolved externals I have no idea what the matter is. I will greatly appreciate it if you can help me out.

3 2

NEWBIE: Undefined references: How do I find the library that resolves an undefined reference
by JENNINGS, LYNN M NH-03 USAF AFMC 517 SMXS/MXDPB 30 May '17

30 May '17

NEWBIE question: Undefined references: How do I find the library that resolves an undefined reference. For example, the output for the gcc linker running in MinGW shows: C:/boost/boost/asio/detail/impl/winsock_init.ipp:39: Undefined reference to `WSAStartup@8' I have googled the documentation a number of ways, but I cannot find the library that will resolve this error. I am sure that this is a common problem. Please point me to the documentation so I can fix this and the undefined references. Thanks!

4 3

boost::process async io and reading stdout line by line
by niXman 29 May '17

29 May '17

Hi, Is it possible to use boost::process async io and reading the stdout line by line? Thanks. -- Regards, niXman ___________________________________________________ Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows: https://sf.net/p/mingw-w64/

2 1

[Move] unique_ptr with boost vector container (C++98)
by Gene Kang 29 May '17

29 May '17

I’m using boost::movelib::unique_ptr with a polymorphic container of type boost::container::vector and getting a compiler error that I can’t seem to figure out (see code sample and attached compiler output). Note, this error occurs when compiling without C++11 support w/ x86-64 gcc 4.9.3. When compiling w/ C++11 support (e.g. -std=c++11) the code compiles fine. Any ideas ? Thanks in advance for any help on this. ---------------------------------------------------- #include <boost/move/unique_ptr.hpp> #include <boost/container/vector.hpp> class FooA { public: FooA() {} virtual ~FooA() {} virtual void execute() {} }; class FooB : public FooA { public: FooB() {} virtual void execute() {} }; int main() { typedef boost::movelib::unique_ptr<FooA> FooAPtr; typedef boost::movelib::unique_ptr<FooB> FooBPtr; boost::container::vector<FooAPtr> fooVector; FooBPtr fooBPtr(new FooB); fooVector.push_back(boost::move(fooBPtr)); return 0; }

2 2

Re: [Boost-users] [outcome] Possible extensions/changes to std::experimental::expected
by Vicente J. Botet Escriba 25 May '17

25 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

1 0

[Regex] Has build location changed between 1.34.1 and 1.64.0 ?
by Kerry, Richard 23 May '17

23 May '17

I've just added Boost Regex to a new project. It is the first time I've done that for quite a long time (several years) and I'm left wondering whether Regex's standard build location has been changed, or whether I've missed a detail in the instructions. The last one I did was Boost version 1.34.1, under Visual Studio 6. The one I have just done is Boost version 1.64.0, under Visual Studio 12, aka Visual Studio 2013. To build 1.34.1 (on VC6) I run "bjam --toolset=msvc --with-regex stage". This creates two folders - "bin.v2" and "stage". Bin.v2 is where all the intermediate files are written. Stage/lib is where the final outputs are written. There are a number of different ones built; for all the various static/dynamic, single/multi-threading, debug/release options. Because of the auto-link stuff I just #include <boost/regex.hpp> in my project, and because of the use of #pragma comments in boost, the Link pass picks up the correct library file-name, provided I have included $(BOOSTDIR)\stage\lib in the linker's list of folders to search. (%BOOSTDIR% being my chosen download/build location) To build 1.64.0 I've followed the current instructions. I ran "b2 regex", which built a dll, which is not what I want. I then ran "b2 regex link=static", which build the static lib I wanted. However, the lib is left in a folder a long way down from the bin.v2 folder, which is where I expected it to be. It's in bin.v2\libs\regex\build\msvc-12\debug\link-static\threading-multi. Hence, I need to know all the build settings to work out the folder name. On the file-name side this is all hidden from my by the auto-link system, which builds the lib file's name from the various option settings. Having the name built automatically but not the path leads me to suspect I've missed something.... So: Is there an instruction I've missed to get all the built products (dlls or libs) put in a common (not too deep) location ? (so the auto-link system will be sufficient to find it given just one linker folder location) Is there an instruction I've missed to get all the combinations (static/dynamic, single/multi-threading, debug/release) built ? (rather than one at a time) Regards, Richard. Richard Kerry BNCS Engineer, SI SOL Telco & Media Vertical Practice T: +44 (0)20 3618 2669 M: +44 (0)7812 325518 4 Triton Square, Regent’s Place, London NW1 3HG richard.kerry(a)atos.net<mailto:richard.kerry@atos.net> This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.</ Atos, Atos Consulting, Worldline and Canopy The Open Cloud Company are trading names used by the Atos group. The following trading entities are registered in England and Wales: Atos IT Services UK Limited (registered number 01245534), Atos Consulting Limited (registered number 04312380), Atos Worldline UK Limited (registered number 08514184) and Canopy The Open Cloud Company Limited (registration number 08011902). The registered office for each is at 4 Triton Square, Regent’s Place, London, NW1 3HG.The VAT No. for each is: GB232327983. This e-mail and the documents attached are confidential and intended solely for the addressee, and may contain confidential or privileged information. If you receive this e-mail in error, you are not authorised to copy, disclose, use or retain it. Please notify the sender immediately and delete this email from your systems. As emails may be intercepted, amended or lost, they are not secure. Atos therefore can accept no liability for any errors or their content. Although Atos endeavours to maintain a virus-free network, we do not warrant that this transmission is virus-free and can accept no liability for any damages resulting from any virus transmitted. The risks are deemed to be accepted by everyone who communicates with Atos by email.

3 5

[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 3

[Test] Message from unexpected exceptions
by Leo Carreon 23 May '17

23 May '17

Hi, Is there a way of configuring Boost.Test to display the message from unexpected exceptions? I’m asking because at the moment whenever an unexpected exception is encountered by Boost.Test, it displays the type of the exception but not the message that goes with it making it more difficult to track down where the exception came from. If apart from the type of the exception the exception message is included, it could quicken the resolution of the issue. Kind regards, Leo

3 4

Re: [Boost-users] [boost] Boost.Outcome review - First questions
by Vicente J. Botet Escriba 21 May '17

21 May '17

Le 21/05/2017 à 15:59, Niall Douglas via Boost a écrit : >> 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(). > If you don't check before using .value(), it may throw > bad_expected_access<E>. So you have to fix the text. > >> Instead of some deviation, I would expect a report of all deviations and >> a rationale explaining why it is better to do this way. > I believe the list of deviations is complete, apart from the defects you > found listed below which I will fix. Explaining why I deviate in detail > isn't appropriate for the Outcome docs, I have raised why with you > privately at length. Depending on what is decided at Toronto, I may > write up remaining concerns into a WG21 paper, but in the end Outcome's > Expected will track yours more closely than it has, so whatever you > decide I'll do too. My idea is to forward your concerns to Toronto, but for that I need arguments that I expected to find in this section. > >> # "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>? > Outcome doesn't do SFINAE on its main constructors. It relies on simple > overloading which is much lower compile time cost. Maybe it has lower compile time, but it is not correct, isn't it? Would you suggest that std::expect shouldn't do SFINAE? > >> I don't see what |expected<void, void> could mean. > It's legal in the LEWG Expected proposal. It's essentially a boolean. Hugh! > >> # |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? > basic_monad, separate to Expected, implements implicit conversion from > any less representative form to any more representative form. So: Could you point me to the documentation? > > result<void> => result<T> > result<T> => outcome<T> > expected<void, X> => expected<T, X> > > ... and so on. > > That's why implementing unexpected_type as an alias of expected<void, E> > "just works". > > A current outstanding bug > (https://github.com/ned14/boost.outcome/issues/16) is failure to compile: > > result<void> => result<T> > > ... when T has no default constructor because a valued void state turns > into a default constructed T state. That *should* fail to compile of > course, but the as_void() free function also fails to compile that, and > it should work because otherwise the BOOST_OUTCOME_TRY() machinery fails > to compile when the T of the enclosing function doesn't have a default > constructor. It's my next issue to fix, it'll be done soon. But what is the meaning if the result<T> if result<void> has a value? > >> # 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. > The most important problem by far is the inability to do > make_expected<const Foo>(Foo()) => expected<const Foo>. I suppose const > volatile also should be supported. I have already raised this with you, > you said it will be discussed at Toronto. Yes, it will. This is not a good reason to don't provide what already is in or what we discussed together. > > Whatever you end up doing to make_expected() etc to enable const T and > const E, I will replicate in Outcome's Expected. Until then I deviate to > allow those. expected<const T, const E> is useful sometimes. How you deviation allows it in a better way? > >> # 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? > You don't cause .value_or() to surprisingly fail to compile when T lacks > a move or copy constructor. The reference returning edition does not > impose the requirement for T to have a move or copy constructor. This > choice for .value_or() interferes less on end users. Do you have cases where expected<T,E> has a T that is not move/copy constructible? How can you return it? > The fact optional implemented .value_or() with a return by value is a > mistake. Expected need not repeat that mistake. Could you point me to the C++ standard std::optional defect? Have you created one? > >> # 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. > Correct. static constexpr bools provide the information instead. If > reviewers like it, we may inject correct answers into namespace std for > the type traits (this is permitted by the C++ standard). Could you elaborate? > >> 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. > Already logged to https://github.com/ned14/boost.outcome/issues/26 > >> * it is not clear from the reference documentation if expected<void,E> >> is valid? > Do you mean there is no reference in the API docs to an expected<void, > E> specialisation? I didn't add one as I figured it was self evident and > unsurprising. Also, if we document expected<void, E>, we'd have to also > do result<void>, outcome<void>, expected<void, void> etc and to be > honest, they all behave exactly as you'd expect a void typed edition > would: wherever there is a T, you get T=void. Nothing special. Maybe or maybe not. What is the signature of value_or? > >> |* |is expected<T,E> the sum type of T, E and empty? and exception_ptr? > expected<T, E> may only have the state of T or E. The valueless by > exception state has been eliminated recently in develop branch. Is this the case also for outcome/result/option? > >> |"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. > Those static asserts are gone from develop branch as we now fully > implement the never empty guarantee for Expected. Is there > >> What are the exception warranties for |error_code_extended? > It never throws, not ever. > > This is pretty clear in the reference docs. Everything is marked noexcept. I don't see it in https://ned14.github.io/boost.outcome/classboost_1_1outcome_1_1v1__xxx_1_1e… Could you point me where noexcept is? > >> What are the exception warranties for |outcome<T>||? > The tutorial covers those. The reference docs will too when issue #26 is > implemented. The noexcept modifiers on most of the member functions are > pretty clear however. This is the kind of information we want on the reference documentation. Could you tell us what the issue #26 The default actions for each of .value(), .error(), .exception() etc need to be spelled out in the reference docs <https://github.com/ned14/boost.outcome/issues/26> will add to the docs and how this issue is related? What about the other functions, constructors, assignments ... > >> * 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. > The former has lower compile time load for valued default constructing > an instance, and it's the constructor used internally by helper > functions etc. Maybe this should be private and these helper functions friend. Id expected is default constructible, why do we need it? What is the difference between constexpr expected () and constexpr expected (value_t _) ? > The latter is there for emplacement construction for > those willing to pay the compile time cost. > >> * default constructor >> >> constexpr expected () noexcept(is_nothrow_default_constructible) >> Default constructor. >> >> This doesn't say what the default constructor does. > As per LEWG Expected, T is default constructed. The reference docs will > be fixed with issue #26. I insists #26 has nothing to do with constructors and I'm (we're) interested in knowing how this will be fixed. > >> * 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); > Ah yes I had forgotten about that. > > You are correct, but I left it unfixed to remind me to ask here what > would be a suitable unit test for testing an "initializer_list il, > Args&&... args" constructor where the Args&&... gets used correctly. I > was unsure of the semantics. Take a look at std::optional test if you are curious. > > Also, it's logged to https://github.com/ned14/boost.outcome/issues/27. > >> * What is void_rebound and where it is defined > It was accidentally omitted from the reference docs. It is "using > void_rebound = rebind<void>". Logged to > https://github.com/ned14/boost.outcome/issues/28. > >> * construction from error type >> >> Why do you prefer an implicit conversion. This deviation must be in the >> rationale of the differences. > The deviations list already explains that types T and E cannot be > convertible into one another because we use simple overloading to avoid > using SFINAE to keep compile time load low. > > Code written for LEWG Expected will, unless types T and E are > convertible into one another, work as expected. You don't answer to my question. Why implicit? What is wrong with the constructor expected(unexpect_t, error) ? > >> * raw types >> >> It is not clear what is the difference between xxx and raw_xxx > Logged to https://github.com/ned14/boost.outcome/issues/29 Thanks for creating the issue, but I'm interested in knowing it now during the review. Otherwise I couldn't accept even conditionally the library. > >> * what is the sizeof expected <T,E>? > It says already at the top of the page. It's max(24, sizeof(R)+8) on 64 > bit CPUs. An now that you will ensure the never empty warranties? > >> * What is expected<Policy> in > Looks like a misparse by doxygen. Such a thing doesn't exist. Logged to > https://github.com/ned14/boost.outcome/issues/30 > >> * bool conversion should be explicit > Another doxygen bug. Logged to > https://github.com/ned14/boost.outcome/issues/31. > >> * is_ready has nothing to be with expected. > Already removed from develop branch. > >> * Shouldn't value_or return by value? otherwise what would be the >> difference between get_or and value_or? > The get_*() family of functions is scheduled to be removed as per peer > review feedback by https://github.com/ned14/boost.outcome/issues/24 Okay. > >> * emplace. Missing overload >> >> >> template <class U, class... Args> >> void emplace(initializer_list, Args&&...); > Great catch! Logged to https://github.com/ned14/boost.outcome/issues/32 > >> * 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. > Issue #26 will fix these. > >> * what error_or >> <https://ned14.github.io/boost.outcome/structboost_1_1outcome_1_1v1__xxx_1_1…> >> returns if it contains an exception? > The or parameter. Errored does not include excepted, but excepted > includes errored because an error code is emitted as an exception_ptr to > a system_error containing that error code. Hugh! Too complex. > >> * Missing overload for get_unexpected. In addition it doesn't return an >> unexpected_type. >> >> constexpr const E & get_unexpected () const; > I didn't realise there were rvalue, lvalue, const rvalue and const > lvalue overloads. That must be a recent thing. Logged to > https://github.com/ned14/boost.outcome/issues/33. > > The return by E rather than expected<void, E> is by design. Remember we > permit implicit construction from E, so this is safe and works well. > Again, code written for LEWG Expected should never notice this > implementation detail. Why? if the signatures doesn't match I will have sure a problem somewhere. > > (the real cause for this deviation is because the policy classes cannot > return types still being fabricated, so they cannot return an > expected<void, E>. If this deviation ever should become a problem, I can > relocate get_unexpected to the main class and enable_if it, or else use > a trampoline type. But I believe the existing form replicates the same > semantics, it should be fine) This is what I don't like of your library. In order to have a common implementation you sacrifice the concrete interfaces. I prefer to have concrete classes that provide the interface is the most adapted to these classes and then have an adaptation to some type of classes requirement when I need to do generic code. This something that I remarked since the beginning of your library. The basic_monad class is over-engineered IMHO. > Vicente thanks very much for such detailed feedback. It was very valuable. > Niall, please, don't wait until the review is finished to tell us how the issues will be fixed. You could do it on each issue and come back in this ML. Best, Vicente

1 0