- Boost - lists.boost.org

Detail headers moved
by Belcourt, Kenneth 26 May '17

26 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 25 May '17

25 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