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

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

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

21 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

1 0

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

20 May '17

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

1 0

Issue with cross-compiling boost
by Roy Kleefman 17 May '17

17 May '17

Hello all, I am trying to cross-compile the boost libraries for an ARM based linux system. The system is an FX30 IoT gateway by Sierra Wireless. It comes with a dedicated, Eclipse based, development studio, which supplies the cross-compiler & a disk image with all the required headers & libraries to cross-compile to. For starters, I've created a user-config.jam file in my home directory with the following contents (my apologies on this being a bit hard to read, I had to use absolute paths or else the cross-compiler would complain): using gcc : arm : /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ : <cxxflags>--sysroot=/home/developer /legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi <include>~/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi <linkflags>-L/home/developer /legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/lib -L/home/developer /legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/local/lib <compileflags>-v ; As you can see I've set the sysroot to the directory that is the / directory of the disk image. I've also set library paths to the disk image's /usr/lib & /usr/local/lib directories. I also tried several variations on setting the include path to point to the disk image, but I run into issues when compiling the boost libraries. When the compiler hits the alloc_lib.c file, it errors out on: COLLECT_GCC=/home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ Target: arm-poky-linux-gnueabi Configured with: /work/build_src/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/configure --build=x86_64-linux --host=x86_64-pokysdk-linux --target=arm-poky-linux-gnueabi --prefix=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr --exec_prefix=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr --bindir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi --sbindir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi --libexecdir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi --datadir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/share --sysconfdir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/etc --sharedstatedir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/com --localstatedir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/var --libdir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/lib/arm-poky-linux-gnueabi --includedir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/include --oldincludedir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/include --infodir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/share/info --mandir=/opt/swi/y17-ext/sysroots/x86_64-pokysdk-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/work/build_src/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/opt/swi/y17-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.1 --with-build-time-tools=/work/build_src/tmp/sysroots/x86_64-linux/usr/arm-poky-linux-gnueabi/bin --with-sysroot=/opt/swi/y17-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi --with-build-sysroot=/work/build_src/tmp/sysroots/swi-mdm9x15 --enable-poison-system-directories --with-mpfr=/work/build_src/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --with-mpc=/work/build_src/tmp/sysroots/x86_64-nativesdk-pokysdk-linux --enable-nls --with-arch=armv7-a Thread model: posix gcc version 4.9.1 (GCC) COLLECT_GCC_OPTIONS='-O3' '-finline-functions' '-Wno-inline' '-Wall' '-v' '-pthread' '-D' 'BOOST_ALL_NO_LIB=1' '-D' 'BOOST_CONTAINER_STATIC_LINK=1' '-D' 'NDEBUG' '-I' '.' '-c' '-o' 'bin.v2/libs/container/build/gcc-arm/release/link-static/threading-multi/alloc_lib.o' '-shared-libgcc' '-march=armv7-a' '-mtls-dialect=gnu' /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/cc1 -quiet -v -I . -iprefix /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ -D_REENTRANT -D BOOST_ALL_NO_LIB=1 -D BOOST_CONTAINER_STATIC_LINK=1 -D NDEBUG libs/container/src/alloc_lib.c -quiet -dumpbase alloc_lib.c -march=armv7-a -mtls-dialect=gnu -auxbase-strip bin.v2/libs/container/build/gcc-arm/release/link-static/threading-multi/alloc_lib.o -O3 -Wno-inline -Wall -version -finline-functions -o /tmp/ccNP4WY6.s GNU C (GCC) version 4.9.1 (arm-poky-linux-gnueabi) compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory "/home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/../../../../../arm-poky-linux-gnueabi/include" ignoring duplicate directory "/home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/../../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/include" ignoring nonexistent directory "/opt/swi/y17-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/lib/gcc/arm-poky-linux-gnueabi/4.9.1/include" ignoring nonexistent directory "/opt/swi/y17-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/local/include" ignoring duplicate directory "/home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/../../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/include-fixed" ignoring nonexistent directory "/home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/../../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/../../../../../arm-poky-linux-gnueabi/include" ignoring nonexistent directory "/opt/swi/y17-ext/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include" #include "..." search starts here: #include <...> search starts here: . /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/include /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/include-fixed End of search list. GNU C (GCC) version 4.9.1 (arm-poky-linux-gnueabi) compiled by GNU C version 4.9.1, GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 89d75e59a6fc83bde96963c802ac00fb In file included from libs/container/src/alloc_lib.c:19:0: libs/container/src/dlmalloc_ext_2_8_6.c:13:100: fatal error: errno.h: No such file or directory #include "errno.h" //dlmalloc bug EINVAL is used in posix_memalign without checking LACKS_ERRNO_H ^ compilation terminated. "/home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++" -x c -O3 -finline-functions -Wno-inline -Wall -v -pthread -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTAINER_STATIC_LINK=1 -DNDEBUG -I"." -c -o "bin.v2/libs/container/build/gcc-arm/release/link-static/threading-multi/alloc_lib.o" "libs/container/src/alloc_lib.c" ...failed gcc.compile.c bin.v2/libs/container/build/gcc-arm/release/link-static/threading-multi/alloc_lib.o... ...failed updating 1 target... ...updated 123 targets... Which I find strange, because the "errno.h" header is available on the disk image. It is found in these directories: <sysroot>/usr/include/linux/errno.h <sysroot>/usr/include/bits/errno.h <sysroot>/usr/include/sys/errno.h <sysroot>/usr/include/asm-generic/errno.h <sysroot>/usr/include/asm-generic/errno-base.h <sysroot>/usr/include/errno.h <sysroot>/usr/include/asm/errno.h What struck me as odd is that the include search for this file has a lot shorter search list than for other files. For example, searching for headers for libboost_atomic, it looks in more directories: #include "..." search starts here: #include <...> search starts here: . /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/include /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/../../lib/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/include-fixed /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.1 /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.1/arm-poky-linux-gnueabi /home/developer/legato/packages/legato.toolchain.1.7.3.SWI9X15Y_07112100-wp85-wp750x-native-x86_64-201701091132/resources/native/sysroots/armv7a-vfp-neon-poky-linux-gnueabi/usr/include/c++/4.9.1/backward Can anybody help me with this problem? Kind regards, Roy Kleefman [cid:image001.jpg@01D2CEED.E27ADF00] Rohill * Edisonstraat 12 * 7903 AN Hoogeveen * The Netherlands Phone: +31-528-263355 * Fax: +31-528-271844 * www.rohill.com<http://www.rohill.com/> Chamber of Commerce Meppel registration no. 09084362 This email, including any attached files, is confidential, may be legally privileged, and is solely for the intended recipient(s). If you have received this email in error, please destroy it and notify Rohill immediately. Any unauthorised use, dissemination, disclosure, copying or printing is strictly prohibited. Thank you. [cid:image003.jpg@01D2CEED.E27ADF00]<http://www.criticalcommunicationsworld.com/>

1 0

UTF: test/included/unit_test.hpp vs test/unit_test.hpp
by Manav Bhatia 15 May '17

15 May '17

Hi, I am using the UTF in my code. Below is the key component of my code that I have been using on Mac for a few years with boost installed from macports. #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MODULE MAST_TESTS #include <boost/test/unit_test.hpp> // C++ includes #include <memory> struct GlobalTestFixture { GlobalTestFixture() { /* my code here */ } ~GlobalTestFixture() { } }; BOOST_GLOBAL_FIXTURE( GlobalTestFixture ); A few days ago I started using this code on Ubuntu and kept getting segmentation faults with random values being returned for boost::unit_test::framework::master_test_suite().argc I managed to get rid of this problem by changing the included header to #include <boost/test/included/unit_test.hpp> I have seen the description here: http://www.boost.org/doc/libs/1_48_0/libs/test/doc/html/utf/compilation/dir… <http://www.boost.org/doc/libs/1_48_0/libs/test/doc/html/utf/compilation/dir…>. However, I am not quite able to follow why this problem occurred on Ubuntu (with system boost library) when I was still linking against the precompiled library (version 1.58). Is there a test I can include in my code to automatically switch from one include to the other? I will appreciate some guidance. Regards, Manav

3 2

Test: Skip test from fixture
by Florian Lindner 15 May '17

15 May '17

Hello, given I have a test with a fixture. How can I skip that test from within the fixture? Thanks, Florian

2 1

(no subject)
by Daniel Estermann 14 May '17

14 May '17

Hello everybody, I am trying to build HPX (https://github.com/STEllAR-GROUP/hpx) which uses Boost under Cygwin and I bumped into an incompatibility issue between the class boost::asio::detail::winsock_init_base and the WinSocket-API exposed by Cygwin. The error summary: the types of variable members in winsock_init_base::data are long (defined in boost/asio/detail/winsock_init.hpp). These variable are passed to functions _InterlockedIncrement, _InterlockedExchange etc (called from boost/asio/detail/impl/winsock_init.ipp). But there are no functions defined in Cygwin (in headers in /usr/include/w32api) expecting a long parameter. Here you can see the full gcc output: https://pastebin.com/raw/8MDa8QXJ I also produced the the preprocessor output which I zipped and uploaded to https://www.dropbox.com/s/anmjsjnvq7lnesr/hpx_init.cpp.i.zip?dl=0 Am I overlooking anything or is this really an incompatibility issue?

1 0

Context and coroutine for ARM
by Daniel Estermann 14 May '17

14 May '17

I am trying to cross compile boost 1.63 for Raspberry Pi, i.e. for an ARM core. But the build fails for boost-coroutine and boost-context. Here is my build log http://sprunge.us/NVDd As far as I can see from development files in https://github.com/ boostorg/context/tree/develop/src/asm ARM is supported at least by boost-context. Is there anything I can do about or any progress for this issue? If not, is there an older version I should try? Regards

5 18

Using the (new) C++ standard library in boost::dll
by Benjamin Buch 12 May '17

12 May '17

The boost::dll depends on 4 different boost-libraries which all have counterparts in the C++17 standard library. Worse, two of them (system & filesystem) are not header-only libraries, so you need to link against these libraries. Is it possible and planned to use the standard library counterparts as plug in replacement for these boost dependencies in a future release? In my opinion this would improve the usability massively, especially when you already use this counterparts in the rest of your program. Best regards, Benjamin

3 2

boost::process::search_path() and compound cmd
by niXman 12 May '17

12 May '17

Hi, I need to execute the 'stdbuf -oL -eL python scrypt.py' cmd but if I write the: auto p = boost::process::search_path("stdbuf -oL -eL python2"); boost::process::child c(p, "script.py"); c.wait(); I get the exception with 'execve failed: Permission denied' message. My question is, what should I change in my example for executing the 'stdbuf -oL -eL python2 scrypt.py' cmd? 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