- Boost - lists.preview.boost.org

[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