- Boost - lists.preview.boost.org

Re: [boost] [boostorg/python] Building against multiple python implementations broken on 1.70 (#262)
by Stefan Seefeld 15 Apr '19

15 Apr '19

On 2019-04-14 7:50 p.m., Peter Dimov wrote: > > I'll need to look into this. Apparently, |FindBoost.cmake| solves this > by forcing the user to specify the version in |find_package(Boost > COMPONENTS python27)|, but the CMake configuration files installed by > 1.70 only take |find_package(Boost COMPONENTS python)|, so multiple > versions installed at the same time are a problem. > > In the meantime, you can add |--no-cmake-config| to your |b2 install| > command line to skip the installation of CMake configuration files, > which ought to give you the 1.69 behavior back. > This is *exactly* the kind of situation I was afraid of when I argued strongly against adding CMake support to my own projects: Before I had to deal with B2 issues that I had difficulties resolving myself. Now I have to deal with B2 *and* CMake issues, being even more dependent on others. That's not my definition of progress. Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 4

[variant2] never-empty guarantee considered harmful
by Andrzej Krzemienski 15 Apr '19

15 Apr '19

Hi Everyone, I waned to re-iterate my concerns regarding the never-empty guarantee provided by variant2 (as well as by boost::variant). Sorry for starting a yet another thread, but I think it necessary to cleanse, group and structure the information scattered among a number of threads. I think that the never-empty variant deceives people into thinking that it offers something useful and important, but in fact it does not, and more, it can encourage people to trust that they have some guarantee which they haven't, and owing to this to write buggy code. The solution that never-empty variant offers is similar to another common idea of replacing undefined behavior with *any *defined behavior whatsoever, and that is supposed to be "safe" because programmers no longer see symptoms of their bugs. Let me digress on the subject of UB for a second. UB is always caused by a bug in the program. Thus if the program had no bugs, it would have no UB. But many people are very afraid of UB per se, and less afraid of bugs. They will divert much attention to prevent UB at surprisingly high cost, but focus less on preventing their bugs. UB is a useful symptom of a bug and therefore can help detect and remove bugs, but people are sometimes so afraid of UB that they loose this connection to the extent that they are willing to remove the link between the two and get rid of potential UB even at the cost of concealing the bugs. And they consider it "safe". For instance, someone writes a sequence container class and faces the problem. I will need to provide access to elements by index, but people will give me bad indexes (because they can), this would be a UB, and I do not want a UB, therefore I apply a "safety" feature. Whenever someone gives me bad index, I will return a reference to the first element. Sure, it is surprising, and likely not what the caller wanted, but it is better than UB. And in case I have no elements in my container I will default-construct one in the container. Sure it is not nice to to increase the size of the container only because someone gave me the wrong index, but... *anything is better than UB.* I wonder if everyone reading this mail will agree with me that reasoning "anything is better than UB" is wrong. The author of this "safe" container calls his container "safe" because whatever bugs his callers have, they will never trigger UB *in his library*. Maybe in another library, at another level, but not in his component. In the end we will get programs that will cause self-driving cars to crash and kill people, space rockets to explode, but the "safe" program itself will never crash. Instead the author of the "safe" container should be focusing on something else. Why is my caller giving me the wrong index given that he can check my size and easily determine that this index is wrong? The answer is, the programmer probably intended to do something else and this needs to be brought to his attention. Tools like compilers and static analyzers cannot detect bugs in general because they cannot guess our intentions, but they can detect things like UB, so if we keep a correspondence between bugs and UB, we can detect bugs by detecting UB. This has been described in more detail in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1043r0.html (section 6). Now, the situation is similar with the never-empty guarantee of the variant that offers only a basic exception safety guarantee on assignment. Because the guarantee is basic (that is, it is not the strong guarantee), the only thing we can do with it in order not to risk program bugs is, following the Dave's article (https://www.boost.org/community/exception_safety.html) to either destroy or reset the variant that threw from assignment. And this is what correct programs do, and the technique is quite simple: unless objects provide strong exception safety guarantee (or some other guarantee that allows you to reason about the values of objects that threw) they should die in the stack unwinding process. The damage that the never-empty guarantee (implemented by setting unexpected values) does is to encourage people to think that with variant they can do something more than just destroy or reset. And while technically, variant itself is "clean" in this case (it really doesn't invoke UB itself) it causes the code that is using it to be incorrect. Two examples. I may have the following instance: ``` variant2<X, Y, shared_ptr<Z>> v {X{"params"}}; struct Visitor { int operator()(shared_ptr<Z> const& z) { return z->getCount(); } int operator()(X const&) { return 1; } int operator()(Y const&) { return 1; } }; ``` Where X and Y have nasty properties (are declared to potentially throw from move constructor and do not have default constructors). My v could technically store a null pointer at some point. In the visitor I do not check for this eventuality. Someone could say, "you should always check for null pointer, because anything is better than UB", But I know I never will be storing a null pointer there. I use shared_ptr for its ability to share ownership of an object, not for its ability to be null. I guarantee that I will never set the shared_ptr<Z> alternative to nullptr value. Therefore in the visitor I can assume that the pointer is never null. But if I am encouraged by the variant's never-empty guarantee to depart from Dave's guidance not to trust basic-guarantee objects that threw, I may end up in the situation where I start with alternative X, I want to assign alternative Y, but it throws, and because the only type with the default constructor is shared_ptr<Z>, I will get a nullptr value which I never intended. This is not bad yet. But now, if I apply my visitor on my variant, my precondition that the pointer is not null will be violated: ``` variant2<X, Y, shared_ptr<Z>> v {X{"params"}}; BOOST_SCOPE_GUARD(&v) { visit(Visitor{}, v); }; v.emplace<Y>("params"); // throws ``` Now, variant2 fulfills its guarantee: it stores one of the alternatives (of arbitrary choice and arbitrary value), but it injected me the worst possible value of the type with the weak invariant. Thus, variant2's invariant may be strong, but it exploits the weak invariants of the types of the alternatives. And unfortunately, a lot of types, even in the STD, have weak invariants and use the default constructor to set the degenerate state. Thus, my program has UB, and hopefully a crash, because I was deceived by the never-empty guarantee: I thought it would be "safe" to observe such variant that threw. Second example comes from Peter: ``` template<class T> class monitor { T const& v_; T old_; public: explicit monitor(T const& v) : v_(v), old_(v) {} ~monitor() { if( v_ != old_ ) std::clog << "value changed"; } }; ``` Suppose I use it like this: ``` { variant2<X, Y, shared_ptr<Z>> v {shared_ptr<Z>{}}; // let me check if this code sets the v to a non-degenerate value: monitor m {v}; v.emplace<X>("params"); // succeeds v.emplace<Y>("param"); // fails: null pointer set. } // no value change reported ``` although the only state changes I initiated in this block were to set types X and Y, I got the wrong result from the monitor, because the "safe" guarantee of the variant chose some state that corrupted the monitoring logic. variant2 delivers its guarantee as promised: some value is there, but my monitoring is compromised because of its arbitrary choice of value. Note that std::variant does not have this problem: a distinct state is set upon such exception that is always different than any value of any of the alternatives. Of course, this second example has problems of its own. It assumes you can invoke operator== on an arbitrary T of which we know nothing. It assumes that T's invariant allows the values to be compared, but this is not correct an assumption. Type T can have a weak invariant: one that does not even allow comparing two values. You cannot just invoke arbitrary operations on an unknown T in the destructor, if you do not know they exception safety guarantees. T's comparison could potentially throw. Even destructors of generic components such as vector<T> or optional<T> in their non-trivial implementations only invoke operations on concrete types: pointers and bools, but for the T they only call destructors. Peter argues that a call to the operation on a variant could be invoked indirectly form the destructor: destructor calls function f(), function f calls function g(), function g() calls function f() and function h() makes a visitation on the variant. But can you see what this means? I am calling some function f() from the destructor, which is supposed to clean up resources, and I am not sure what f() does, if it does some hidden things beyond my control. This is a buggy code already. Now, to address another argument in favor of never-empty, arbitrary-value-choosing guarantee. Emil says that with never empty-guarantee we can more easily reason about the variant: it is *always* one of the alternatives: rather that "either one of the alternatives or some degenerate state. He argues that once we allow the faintest possibility for the degenerate state, we have to check for it *everywhere*. I think that the simple binary model, "either the weak state does not exist or is potentially everywhere", while it often works for many types is, not adequate to describe the reality of the variant. People need models (which are simplifications of reality) to help them manage complex reality. But models have the downside of not allowing people to see the reality beyond what the models allows them to see. We ave to distinguish "ordinary" weak state and "unusual circumstance" weak state. Types like unique_ptr or fstream have ordinary weak state: it is created by a constructor. Worse, by the default constructor, so if you just declare the variable name and forget about parameters you immediately get the weak state. It is easy to obtain this state. And therefore in many places we need to be prepare to handle them. But other types (which we have fewer in STD: only std::variant, I think) can have only "unusual circumstance" weak state: you cannot initialize the object to contain this state (unless you move/copy construct from another object that already has one). You can only get it in situations that for other reasons require special caution from programmers. I am aware of two: * when an object is manually moved from (by explicitly casting an lvalue to an rvalue reference, which std::move() does) * when a mutable operation on an object with basic exception safety guarantee threw an exception. In the first situation, in a generic context where we work with an unknown type T, after the move an object is in a valid but unspecified state. Type T is allowed to have a very weak invariant: so weak that even operator== may not be allowed to be invoked. In this state the only correct thing we can do is to either let the object die or reset its value (the only common way for resetting the value for different types is assignment of a non-degenerate value). Working under the assumption that programmers are aware of these constraints and are willing to adhere to them, we get confidence that these moved-from values will not be observed. (Of course this does not apply to types which choose to guarantee more after move.) We can design a resource-handling type, such as a socket, whose default constructor acquires the first available port, and leaves the object in a "strong" state, ready to work. there is no way to initialize objects of this type to a degenerate value. but if these sockets are move-constructible, the moved from object will have to store the degenerate value. But it would be pointless to check it anywhere in the program. We could only see it if programmers did not adhere to the rule, "only assign to or destroy the moved from objects, unless you know your object offers more guarantees". If programmers do not adhere to this rule, rather than covering up for their bugs, socket should make the UB as explicit as possible in order to assist static analyzers and tools in detecting such programmer's misuse of the moved-from state. Similarly with the after-throw state from the basic guarantee operation. The language cannot enforce this, but programmers are required to adhere to the rule: the only correct operations to be invoked in that case is to destroy the object or to reset it. again, if programmers do other things this is a bug and the type should try to reflect that in a controlled UB, rather than pretending that everything is fine and causing bugs later in unpredictable places, as was shown in the examples above. Insisting that unusual-circumstance weak state should be checked *everywhere* is depriving oneself of the ability to see the engineering trade-offs clearly. We do not have to distinguish "ordinary" and "unusual-circumstance" weak states in most of other types (nearly all types) because they do not pose so many implementation difficulties as variant does: implementing never empty guarantee costs too much in terms of run-time or spatial efficiency. For the sake of the simplicity of the model we cannot sacrifice too much efficiency. Given that efficient implementation of variant does not fit into the simple model, "either I have a strong invariant or not", one option is to provide a misleading and/or never-empty guarantee. But another option is to acknowledge that the simple model is no longer sufficient, and adapt a new one: more complex but one that better reflects the reality: we have two invariants: one that applies in normal code (where every function can be freely called and a weaker one that applies in circumstances that already require special caution from programmers. This is the C++ way: we deal with UB which some other languages do not have at all:this is more complex a task but allows for faster binaries and better bug detection. In a similar vein paper "Fixing Relations" ( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1248r0.html) has been recently adopted in the C++ Standards Committee. The proposal compromised a nice and simple mathematical model, but this part of the model stood in a way to use some STL algorithms efficiently. C++ is not an easy language, and by trying to make it appear simpler than it is, we might only confuse the new programmers. One more thing, it is not the surprising value that variant2 may set upon the exception that bothers me the most. It is rather that indirectly it encourages programmers to think that it is fine or "safe" to read the value of the object that has been moved from or that threw from the basic-guarantee operation. We do not want to suggest that. Finally, all the above reasoning would not apply if variant offered a strong guarantee on assignment/emplacement for cases where the alternative needs to be changed. In that case: 1. It is perfectly fine to observe the state of the object that threw. 2. No surprising, potentially weak-state, value is ever fabricated in this case. Regards, &rzej;

4 5

update of release notes for boost-1.70.0
by Oliver Kowalke 15 Apr '19

15 Apr '19

Hi, I've added 3 pull requests for boost/website... could you apply the patches and re-create the release notes for boost-1.70.0, please?! ty, Oliver

1 0

Re: [boost] [boostorg/python] Building against multiple python implementations broken on 1.70 (#262)
by Stefan Seefeld 15 Apr '19

15 Apr '19

On 2019-04-14 7:50 p.m., Peter Dimov wrote: > > I'll need to look into this. Apparently, |FindBoost.cmake| solves this > by forcing the user to specify the version in |find_package(Boost > COMPONENTS python27)|, but the CMake configuration files installed by > 1.70 only take |find_package(Boost COMPONENTS python)|, so multiple > versions installed at the same time are a problem. > > In the meantime, you can add |--no-cmake-config| to your |b2 install| > command line to skip the installation of CMake configuration files, > which ought to give you the 1.69 behavior back. > This is *exactly* the kind of situation I was afraid of when I argued strongly against adding CMake support to my own projects: Before I had to deal with B2 issues that I had difficulties resolving myself. Now I have to deal with B2 *and* CMake issues, being even more dependent on others. That's not my definition of progress. Stefan -- ...ich hab' noch einen Koffer in Berlin...

1 0

[variant2] Review
by Damian Jarek 14 Apr '19

14 Apr '19

> - What is your evaluation of the design? Variant2 is clearly a superior replacement for the original variant type in boost - Boost.Variant and would be very useful for libraries in Boost and outside of it that are stuck on C++11/14. I strongly believe that triviality propagation should be supported, especially if Variant2 is to be used as the implementation detail of a type like `expected`. As for the hot topic of valuelessness - based on my experience of how variant types are typically used, I think that an implementation should loudly object at compile-time to any operation that could put it in a valueless state - e.g. if emplacing can throw and the type does not have a noexcept move constructor. However, I see that it could be quite inconvenient for many users and I consider the fallback mechanism currently in variant2 to be a good enough compromise. > - What is your evaluation of the implementation? I reviewed the implementation and it looks great. As a test, I replaced the internal variant type in Boost.Beast(beast::detail::variant) with variant2 to compare it against the private lean variant and against std::variant. In terms of compilation time, I've observed no significant difference between std::variant and variant2 when compiling the Boost.Beast test suite. Both were about 10% slower to compile than beast::detail::variant, which can be attributed to the additional header material which must be parsed by the compiler. In terms of runtime performance, I have not observed a significant difference between the 3 variants in terms of requests/second in a test project I use to optimize Boost.Beast performance. Note that Boost.Beast HTTP serialization makes heavy use of a variant to enable sending an HTTP message in as few write calls as possible. As far as I know, all types stored in the variant were "well behaved", so it did not test the double-buffering cases. > - What is your evaluation of the documentation? The documentation is adequate, however, it could use a few examples for users unfamiliar with the concept of sum types. > - What is your evaluation of the potential usefulness of the library? It is a useful replacement for Boost.Variant in C++11/14 libraries both in Boost and outside of Boost. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About 6 hours, most of which where spent on the compilation and runtime benchmarks based on Boost.Beast. > - Are you knowledgeable about the problem domain? I have implemented and used a few variant implementations in embedded code. I have also reimplemented the private and lean beast::detail::variant type on top of Boost.mp11. Conclusion: I recommend that Variant2 is CONDITIONALLY ACCEPTED if: - documentation is extended with usage examples - triviality propagation is implemented

1 0

[gil] Boost.MPL replaced with Boost.MP11
by Mateusz Loskot 14 Apr '19

14 Apr '19

Hi, FYI, Boost.GIL switched from MPL and TypeTraits to MP11 (thank you Peter Dimov!) and C++11 <type_traits>: https://github.com/boostorg/gil/pull/274 This is a significant refactoring and as such it may have introduced bugs. GIL tests coverage had not been 100% and despite we've added numerous new tests, it's still far from complete. Any GIL users out there, if you notice any bugs, please let us know by opening new issue at GitHub or posting to to https://lists.boost.org/boost-gil/ Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

New B2 version, and CI failures.
by Rene Rivera 14 Apr '19

14 Apr '19

As some of you may have noticed, there were some changes to B2 yesterday (4-12). As previously mentioned I merged the start of the B2 C++ engine port to the develop branch. That change included some "improvements" to the building of the B2 executable. One of those improvements may be causing people CI failures. The new build scripts for B2 now respect, and use, the CXX and CXXFLAGS environment variables. As such it means that if you have those set for other reasons it may confuse the B2 build (i.e. bootstrap.sh/bat invocation) and fail that build. If that's the case you will need to clear those variables before invoking boostrap.sh/bat or build.sh/bat. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

4 9

[ASIO] 1.70.0 async_read_until reports undefined symbol with MSVS 2010
by Kenneth Porter 14 Apr '19

14 Apr '19

The following test code (inside #if 1) generates a LNK2019 (unresolved external symbol) with 1.70.0 but links successfully with 1.69.0. Inspecting read_until.hpp, I suspect the problem is with the enable_if expansion being too complex for the older compiler. (Hence the #if0 code which tests the individual conditions, but those seem to work fine.) The same code links with VS2019 and VS2015, and this linked under the previous Boost with VS2010. int _tmain(int argc, _TCHAR* argv[]) { typedef boost::asio::streambuf buftype; #if 0 const bool v1 = boost::asio::is_dynamic_buffer_v1<typename boost::decay<buftype>::type>::value; const bool notv2 = !boost::asio::is_dynamic_buffer_v2<typename boost::decay<buftype>::type>::value; #endif #if 0 void* cond = boost::enable_if< boost::asio::is_dynamic_buffer_v1<typename boost::decay<buftype>::type>::value && !boost::asio::is_dynamic_buffer_v2<typename boost::decay<buftype>::type>::value >::type* 0; #endif #if 1 boost::asio::io_service ios; boost::asio::ip::tcp::socket socket(ios); boost::asio::streambuf buf; boost::asio::async_read_until(socket, buf, '\n', NULL); #endif return 0; }

1 0

[variant2] Review (comparison with other variants)
by Antony Polukhin 14 Apr '19

14 Apr '19

Hi, > - What is your evaluation of the design? Variant2 is very close to the boost::variant and std::variant. The major difference is in treating very rare border case. Let me put it very clear: * I really like the valueless_by_exception() approach of the std::variant. It gives perfectly determinated result in case of an exception during variant assignments, does not dynamically allocate storage and does not double the size of the variant variable. * The approach of existing boost::variant is not perfect. Exception during assignment could lead to the default construction of some type that was not previously held in the variant. This is actually a very creepy behavior: variant<foo, foo2, locked_mutex> v; v = foo2{}; // may suddenly lock a mutex via locked_mutex{} But users do not complain about this. Exceptions during assignments are so rare, that they just don't get hit by the issue. You have to try really really hard to get into the valueless_by_exception() state. The other drawback of boost::variant is that it dynamically allocates memory in some cases that are also quite rare. * Variant2 fixes the second drawback of boost::variant (dynamic allocations). But the first one is still there - in exceptional cases it may default construct something unexpected. Variant2 also may get performance issues because of the doubled size. Smaller data structures better fit the CPU caches. Some platforms allow returning small variables in registers (not on the stack). On some platforms addressing the first ~127 bytes of the structure is more efficient than addressing the other bytes. Increasing the size of a variant2 for dealing with cases that mostly never happen seems unreasonable to me. I'm not saying that the current boost::variant is perfect in border cases (it is not!). I'm saying that std::variant has no such drawbacks at all. Variant2 keeps some issues of the boost::variant and adds new ones. > - What is your evaluation of the implementation? Looks great. Enjoyed it. > - What is your evaluation of the documentation? Did not read very carefully. > - What is your evaluation of the potential usefulness of the library? Useful only if it will get as good as, or better than std::variant. > - Did you try to use the library? With which compiler(s)? Did you > have any problems? Have not used it. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? Quick reading. > - Are you knowledgeable about the problem domain? Yes. I maintain the boost::variant and keep an eye on std::variant implementations. Conclusion: I would recommend to REJECT the Variant2 library in it's current state. My opinion would change if the underlying design changes in favor of explicit valueless_by_exception() state. -- Best regards, Antony Polukhin

1 0

Re: [boost] [variant2] Formal review
by Bjorn Reese 14 Apr '19

14 Apr '19

On 4/13/19 7:26 PM, Bjorn Reese via Boost wrote: > Better compiler error messages would be desirable. For instance, if we > use an illegal visitor that has different return types, then the > compiler error does not give us any hint about the different return > types. A possible solution is to declare a tag and use this in the else-part of mp_if. E.g. struct return_types_must_be_the_same; template<class L> using front_if_same = mp11::mp_if<mp11::mp_apply<mp11::mp_same, L>, mp11::mp_front<L>, return_types_must_be_the_same>;

1 0

crc.hpp:569 msvc warning C4800
by Kenneth Porter 13 Apr '19

13 Apr '19

<https://github.com/boostorg/crc/pull/2> Visual Studio 2010-2019 issue this warning for crc.hpp line 569: warning C4800: "'int' : forcing value to bool 'true' or 'false' (performance warning) bool const quotient = remainder & high_bit_mask; Replace with: bool const quotient = (remainder & high_bit_mask) != 0;

1 0

[build] Bootstrap failures in Appveyor CI
by Andrey Semashev 12 Apr '19

12 Apr '19

Hi, I'm seeing multiple Appveyor job failures at bootstrap stage, here's an example: https://ci.appveyor.com/project/Lastique/winapi/build/job/qnu5dhfcpjx3vh1y The code did not change for quite a while and it was passing before. It first failed after the jobs were triggered by the 1.70 tag. Only some of the jobs have failed, and after I re-ran the jobs, a different set of jobs failed the second time. Is this something related to Boost.Build or superproject?

2 1

[release] Boost 1.70.0
by Marshall Clow 12 Apr '19

12 Apr '19

Release 1.70.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains numerous enhancements and bug fixes for existing libraries. For details, including download links, see < http://www.boost.org/users/news/version_1.70.0> You can also download directly from: < https://dl.bintray.com/boostorg/release/1.70.0/source> SHA-256 sums: ae2bb1b35d1f238e72e3f819b42336f4bd27c9ed2092aab5d87818ccb0c9161a boost_1_70_0.7z 430ae8354789de4fd19ee52f3b1f739e1fba576f0aded0897c3c2bc00fb38778 boost_1_70_0.tar.bz2 882b48708d211a5f48e60b0124cf5863c1534cd544ecd0664bb534a4b5d506e9 boost_1_70_0.tar.gz 48f379b2e90dd1084429aae87d6bdbde9670139fa7569ee856c8c86dd366039d boost_1_70_0.zip To install this release on your system, see < http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Marshall Clow, Daniel James, Micheal Caisse

4 3

[release] 1.71.0 open for merging
by Marshall Clow 12 Apr '19

12 Apr '19

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[variant2] Gavin's review
by Gavin Lambert 12 Apr '19

12 Apr '19

This is my review of Variant2. I vote to ACCEPT this library. However I find the ambiguous state of "expected" a bit too ambiguous (and the "expected" concept in general has caused quite a bit of discussion and contention in the past) so I would prefer that it not be considered part of the library as is, and go through at least a mini-review before entering Boost. I'm not suggesting that this be a formal acceptance condition, however. (I did not look at this type for my review.) I also question whether a more descriptive name than "Variant2" can be used for it, although I recognise that at least starting the library name with "variant" is a good idea to aid discoverability in alphabetic sorting order. - What is your evaluation of the design? As I've stated elsewhere, I feel that if you're willing to pay the cost of double-buffering then you might as well go all-in and implement the strong guarantee as well (or at least a partially strong guarantee, where any attempt to change the stored type provides the full strong guarantee but attempts to assign the same type merely delegates to the underlying type's assignment operation and so provides the same guarantee as that -- this seems sufficiently reasonable and useful to me without sacrificing too much performance, and still lets you single-buffer as an optimisation when all types are noexcept assignable). Having said that, I recognise that others have different lines in the sand, and this is a reasonable design choice within those lines. - What is your evaluation of the implementation? Overall, good. I do have a few minor nitpicks: 1. bad_variant_access's constructor should be "constexpr = default" to preserve constexpr and/or triviality (if std::exception is also constexpr and/or trivially constructible, although this is not the case in VS2017, but could be in other implementations). 2. When std::monostate exists, it should treat both equivalently, for compatibility. (It should not alias its own to std::monostate, as that poses ABI problems if not all code is compiled in C++17 mode.) 3. The duplicated include guard around <boost/mp11.hpp> seems both ugly and unnecessary. Also it should probably be included after <boost/config.hpp>. 4. It's not clear why some of the internal methods (such as _get_impl) have leading underscores while others (such as emplace_impl) do not. It seems inconsistent. 5. It's not clear what purpose the "none" storage type serves (other than apparently requiring the indexing to be offset by one). It seems rather like an empty state... (and the continual offsetting seems inefficient; most of it happens at compile time, but not all). 6. variant_base_impl::_replace has a "requires" comment; why doesn't it have a matching assert? Also, why are these not BOOST_ASSERTs? 7. As discussed elsewhere, a public trait should be provided which lets you static_assert which implementation was actually instantiated. - What is your evaluation of the documentation? It is minimal but sufficient for readers already familiar with std::variant. (And who can read standardese.) It is not sufficient for readers not familiar with std::variant. I think this is mostly fine, but I would prefer the addition of a Motivation and/or Design Rationale section which explains why this is better than std::variant and boost::variant. In future it would also be nice to have a Porting section which explains what code changes are required to move from those to this. - What is your evaluation of the potential usefulness of the library? It seems potentially useful for others, although I would personally have preferred different design choices. - Did you try to use the library? With which compiler(s)? Did you have any problems? I did not try it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read through the documentation and code in moderate detail, but not in-depth. - Are you knowledgeable about the problem domain? I am familiar with variants, but have not as yet used them much in production code.

1 0

Variant2 review
by Phil Endecott 11 Apr '19

11 Apr '19

Dear All, Here is my brief review of Peter Dimov's proposed Boost.Variant2. Sorry that this is not a particularly thorough review. I have read the docs, scanned the code, and followed the discussion on the mailing list; I have not tried to compile or use it. I have recently been using the original Boost.Variant for the first time. I actually started writing code based on std::variant, but then realised that I don't have support for it on one C++14-only platform, so changed to Boost.Variant. It's unfortunate that Boost.Variant has a somewhat different interface from std::variant, so it would be useful to have a Boost variant that is (more) compatible with std::variant. It would also be useful if it were somewhat backward compatible with the old Boost.Variant. The proposed Boost.Variant2 is compatible with std::variant; could some thin layer of compatibility be added to make it possible to port from Boost.Variant code? Specifically, the differences I have noticed are apply_visitor vs. visit and get(V*) vs. get_if. In my case, my stored types are typically raw pointers or small POD structs; none of these can throw during construction/assignment so the complicated arguments about exception guarantees are not applicable. Personally for my current application I'd be happy with a simpler variant that requires noexcept types, or disables assignment for types that might throw, or just doesn't offer an exception safety guarantee. Ideally, perhaps a Boost.Variants *library* should provide a selection of different variants with different features? That leads to the question of naming; we have boost::variant, boost::variant2 and std::variant and those names tell us nothing about how they differ. I'm unsure how or if this can be improved; I'm not suggesting that variant2 should be renamed variant_never_empty_maybe_double_size! But maybe the long-name of the library, i.e. what people will see when they look at the list of Boost libraries, could say "Never empty variant" rather than "Variant 2"? Prior to the review I was familiar with the issue of dynamic allocation, the fact that is is needed in some cases by some variant implementations, and the desire to avoid it. However I was not aware of the alternative of storing two copies of the union, doubling the size of the variant. Much of my work is with memory-constrained systems and unknowingly using twice as much memory as expected would be very undesirable. (I noticed Niall Douglas' comment earlier today "There is nothing wrong, *whatsoever*, with a variant which is sized the largest of its possible states multiplied by two" - I strongly disagree with that.) I'd like to at least get a warning if that were going to happen. A specific concern is that I might accidentally get this fallback due to forgetting to write "noexcept" somewhere (e.g. when using types from older code). On the subject of size, I note that the index is stored in an int, while virtually all uses would surely need fewer than 256 (or certainly 2^16) alternatives. Of course changing the index to uint16_t would not actually help on many platforms due to structure alignment requirements. This makes me wonder about a specialised variant for pointers that uses the spare bits in (most/some) 64-bit pointers to store the variant index. This could usefully be part of a variants *library*. I read Andrzej Krzemienski's comments about the documentation and largely agree with them - though I would say that this library is close enough to std::variant that perhaps the right thing to do is simply to say "go and read about std::variant and then come back here to see the differences". Peter posted a link to some benchmark results last week; those numbers are encouraging and it is also good to know that Peter actually made the effort to measure them! I do wonder how a "trivial" variant supporting only noexcept types would compare, though. Boost.Variant has something called polymorphic_get. I am unclear whether Boost.Variant2 (and/or std::variant) somehow support this functionality. The situation re. expected is unfortunate. I believe really the review should have waited for it to be completed. Peter's comment that if it is decided that it needs to be reviewed then he would remove it and never resubmit it was ... surprisingly undiplomatic? I have always found it a bit odd that Boost requires a thorough review of an initial library submission but nothing at all for later additions. In summary: - I believe the library should be accepted. - It would be great if some compatibility features with Boost.Variant could be added, to make it possible for users of that older library to transition more easily. That is not a condition for acceptance. - I would love to have some way to get a warning or error if the double storage mode had been triggered, or to disable that mode (with an error). - It would be great to see some alternative variants, with different features / trade-offs, included in the library. Ideally, naming of types and headers should allow for that. I'm not suggesting that Peter should be personally expected to supply these alternatives, but perhaps he would accept offerings from others. - I think we should allow Peter to "slip in" his expected when it is ready; I say this largely because Peter has a long history with Boost. Future review managers should try to avoid situations like this arising. Regards, Phil.

7 18

[release] Boost 1.70.0 Release Candidate 2 available
by Marshall Clow 11 Apr '19

11 Apr '19

The second release candidate for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> Changes since rc1: * Boost.Config changes to work better with msvc-14.2 * Boost.Beast bug fixes * Boost.Move bug fix * Boost.Math non-ascii characters removed from header file The SHA256 checksums are as follows: 882b48708d211a5f48e60b0124cf5863c1534cd544ecd0664bb534a4b5d506e9 ./boost_1_70_0_rc2.tar.gz 430ae8354789de4fd19ee52f3b1f739e1fba576f0aded0897c3c2bc00fb38778 ./boost_1_70_0_rc2.tar.bz2 48f379b2e90dd1084429aae87d6bdbde9670139fa7569ee856c8c86dd366039d ./boost_1_70_0_rc2.zip ae2bb1b35d1f238e72e3f819b42336f4bd27c9ed2092aab5d87818ccb0c9161a ./boost_1_70_0_rc2.7z As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

3 5

Problem with generating file_descriptor suing existing pipe file descriptor
by Russell West 10 Apr '19

10 Apr '19

Our program just installed version 69 of Boost and I am running into a compile issue that I am not sure how to resolve. Following is the associated section of C++ code that I am unable to figure out the changes to get it to compile. int filedes[2]; if ( pipe(filedes) == 0) { using namespace boost::iostreams; stream<file_descriptor> results(filedes[0], close_handle); .... .... } The last provided line of code does not compile with a no matching function for call to 'boost::iostreams::file_descriptor::file_descriptor(int&, file_descriptor_flags&)' error. I noticed in the version of the boost file_descriptor.hpp loaded and being used the following exists: #ifdef BOOST_IOSTREAMS_WINDOWS file_descriptor(int fd, file_descriptor_flags); #endif The associated application attempting to be built and deployed is only for servers running the Linux operation system so BOOST_IOSTREAMS_WINDOWS is not enabled, causing the above constructor not to be available. The other constructor available is file_descriptor(handle_type fd, file_descriptor_flags); but I can not figure out how to generate a detail::file_handle from the available int file descriptor generated from above pipe command. Will it cause any issues enabling BOOST_IOSTREAMS_WINDOWS so the required constructor will be available? Thanks ahead of time for your time and feedback. Russell West

2 1

Re: [boost] [Boost-GIL] Image Processing Algorithms
by Mateusz Loskot 10 Apr '19

10 Apr '19

On Wed, 10 Apr 2019 at 18:54, Amir Ali <amirqadir(a)live.com> wrote: > > I really want to do this project even if I am not considered for GSOC. > I am still willing to do it on my own with guidance and supervision from any mentor. There are two mentors who will mentor three students in total. So, we can not offer any supervision to more projects. You are welcome to post your questions to the boost or boost-gil lists, or ask on Gitter room or the Slack channels as any user of / contributor to Boost libraries can do. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Boost-GIL] Image Processing Algorithms
by Amir Ali 10 Apr '19

10 Apr '19

Hi, I am looking for someone to mentor me for my project that is to implement image processing algorithms in Boost-GIL. Here’re some of the algorithms I am aiming to make. Mathematical Morphology (Dilation, Erosion, Opening, Closing) Filters (High pass Filters, Low Pass Filter which includes Gaussian etc) And Other Image enhancement basic algorithms. Regards Amir

2 1

[variant2] Andrzej's review -- documentation
by Andrzej Krzemienski 10 Apr '19

10 Apr '19

Hi Everyone, This is the review of the documentation of variant2. First, the docs assume that the user is already familiar with std::variant or boost::variant, and the introductory part only highlights the difference from std::variant. It does not even mention that variant<X, Y> always stores either X or Y. "Type-safe discriminated union (variant) type," sounds arcane to novices. Notation variant<T…> is also confusing to someone who encounters variant for the first time. There is no initial example. No mention of visit() which is the most important part of the interface. Compare this with Boost.Variant docs: https://www.boost.org/doc/libs/1_69_0/doc/html/variant.html I do not think the library should assume this. Boost libraries are characteristic of documentation that introduces potential users to the problem domain and gives a sort of tutorial that shows how to use the library. I recommend doing the same for variant2. This library does a lot of contortions to avoid the valueless state, but does not describe what the motivation for it is. The docs also do not give a sense of what performance (spacial and runtime) trade offs this library does. For instance, we do not know if the double-buffer scenario th second buffer is within variant's storage or on the heap. Or we do not know about secret moves that the library does internally, which gives surprising behavior to the users that store non-movable types in variant. Consider the following example: ``` struct X {}; struct Guard { explicit Guard(int) {} Guard(Guard&&) = delete; }; variant<X, Guard> v {}; v.emplace<Guard>(1); ``` This works fine with std::variant, but fails to compile with variant2::variant, because the latter requires all the alternative types, at least in one implementaiton of the never-empty trick, to be move-constructible. But this requirement is never listed in either global requirements for alternative types stored in variant, or in the specification of functions `emplace()`. Here's a wandbox example: https://wandbox.org/permlink/hGbRtgzpUrpF0ODy The Reference part of the docs is really good and detailed. Some minor "bug reports" follow. In the specification of functions types `T0` and `Ti` are used, but `T0` or `Ti` are never defined. Wording in the C++ Standard also refers to `T0` and `Ti`, but also provides a definition: In the descriptions that follow, let i be in the range [0, sizeof...(Types)), > and Ti be the ith type in Types. > <http://eel.is/c++draft/variant.ctor#1.sentence-1> > See http://eel.is/c++draft/variant.ctor#1 A similar definition should be put in variant2's documentation. Noexcept specifications use mp_all. this assumes that users of variant2 must be familiar with Boost.mp11. I recommend removing the reference to mp_all and instead use something similar to what the Standard does: http://eel.is/c++draft/variant.ctor#11 Specification of function `emplace<I>()`: It says: > > On exception: If the list of alternatives contains monostate, the > contained value is either unchanged, or monostate{}; > In what situation on exception is the contained value left unchanged? This question applies to the next bullet as well. The specification also doesn't mention that `.emplace<I>()` requires Ti to be move-constructible in some cases. It also says: Throws: Nothing unless the initialization of the new contained value throws. Which sounds strange, because it does throw something. In other places you use "Throws: Any exception thrown by the initialization of the contained value.", which makes more sense. Also, the Standard uses, "Throws: Any exception thrown during the initialization of the contained value. <http://eel.is/c++draft/variant.mod#11.sentence-1>": http://eel.is/c++draft/variant.mod#11 swap(): What does it throw and when? Other functions specify it but this one does not. get<I>(): Specification says, > > If v.index() is I, returns a reference to the object stored in the > variant. Otherwise, throws bad_variant_access. > This means that if I provide an index that is far greater than `sizeof...(T)`, the program should compile fine and throw an exception at run-time. This is not what the implementation does: I get a compile-time error, which is good, but inconsistent with the docs. They need an additional "Requires:" clause. visit(): I think it is underspecified. It is not immediately clear that the first parameter is the visitor and the remaining ones are variants. Parameter names F and V do not convey this clearly. Either use Visitor and Variants... or provide a longer description, even if informal. The docs really should contain an example of `visit()` somewhere. According to the specs, the following should work: ``` void f() {} variant2::visit(f); ``` which is not incorrect, but strange. The std::variant also provides a second overload of `visit` that explicitly defines the return type: http://eel.is/c++draft/variant.visit This overload is not present in variant2. But this fact is not listed in the initial section of the docs that lists the differences between the two libraries. Regards, &rzej;

2 6

[variant2] Comments on documentation
by Bjorn Reese 10 Apr '19

10 Apr '19

The overview states that "variant<T...> is not trivial when all contained types are trivial". Why not? Is this an advantage somehow or an unfortunate limitation? Why is there no tutorial? Why is there no design rationale? Change "variant_npos = -1" into "variant_npos = unspecified" Add a comment about the purpose of valuesless_by_exception(). Without such a comment, the function seems very odd on a "never valueless variant type." The destructor should be marked as noexcept.

4 8

[variant2] Review - Review period extended until April 15
by Michael Caisse 09 Apr '19

09 Apr '19

Hi all - The review period for Boost.Variant2 has bee extended to April 15. Thank you to those who have participated so far. There has been a fair amount of discussion about the merits of never valueless. A core design _feature_ of Variant2 is never valueless. You may have made different trade-offs. Understanding motives makes sense but in this review we are not trying to change this basic design choice. This paper by Peter discusses valueless variants some and may be useful reading: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html> If you haven't started your review yet, you have time! Reviews ranging from detailed discussions of inner workings to a user-perspective of the library and documentation are all helpful. I personally believe we need more user-based reviews in Boost. So, feeling sheepish about reviewing? Don't! Your review is important in the process. Here is one more motivation if you are on the fence ... Peter's code is a joy to read. The library is extremely clean and the code is accessible. There might be all kinds of things you learn from reading the source. Thank you again community for staying involved. We get great libraries when people ask questions, review, and provide input to everything from the docs to the design. Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

GSOC 2019 proposal
by Siddhartha Sen 09 Apr '19

09 Apr '19

Once the proposal is ready, where do I officially submit the pdf?

2 1

Re: [boost] [release] Boost 1.70.0 Release Candidate 1 available
by Ion Gaztañaga 09 Apr '19

09 Apr '19

On 07/04/2019 15:07, Rainer Deyke via Boost-users wrote: > On 07.04.19 14:13, Marshall Clow via Boost-users wrote: >> On Sat, Apr 6, 2019 at 10:53 AM Rainer Deyke via Boost-users < >> boost-users(a)lists.boost.org> wrote: >> >>> On 04.04.19 16:27, Marshall Clow via Boost-users wrote: >>>> As always, the release managers would appreciate it if you download >>>> the candidate of your choice and give building it a try. Please report >>>> both success and failure, and anything else that is noteworthy. >>> >>> boost::movelib::adaptive_merge continues to be broken if >>> iterator_traits<RandIt>::size_type != std::size_t. This breaks >>> boost::container::flat_map when cross-compiling for MacOS. I have >>> previously reported this error here. >>> >>> I consider this a critical error - as in, I won't be able to upgrade to >>> Boost 1.70 at all unless this error is fixed for the release. >>> >> >> This is https://github.com/boostorg/move/issues/25, correct? > > Yes. Sorry for note replying earlier, I was on a trip. The fix is not complicated but several files need to be modified. Committed to develop: https://github.com/boostorg/move/commit/bfdfca0b88fe1cf4e67b42fcacd5e126e93… @Rainer: I've checked this fix in several msvc and gcc's locally. The error report does not contain any example for the bug, so I don't know if I've fixed your use case. I don't know if we are still on time for 1.70. Best, Ion

4 5