- Boost - lists.preview.boost.org

Re: [boost] [variant] Heads-up!
by Nikita Kniazev 29 Apr '19

29 Apr '19

There seems to be misunderstanding of what the thread is about. The short sum-up of the changes: Nothing changed for users that does not use recursive variant. The changes were applied mainly for recursive_wrapper, and affect recursive variant indirectly. The PR was proposed as a solution for two major recursive variant problems: * Move-only types support * Poor move performance (because of this one Spirit has its own variant) Most of the users are not affected by recursive_wrapper move constructor change. To hit it you have to visit (either directly, or with applying comparison operators) a recursive moved-out variant. > have to agree with Steven. Never empty guarantee is a crucial difference between Boost.Variant and std::variant. std::variant has no recursive variant support. In the common field nothing changed. See the comment above. > If the one negative is adding UB to valid existing code at the next point release, doesn't that outweigh any number of positive outcomes? I do not think there even a single user that visits moved-out variants. There is an assertation for such usage though. > Why wouldn't this be an opt-in strategy - this property of moves has been established for years now. Because it solves the bigger problems and for much more users that it potentially breaks.

2 2

[MP11] Loosing const-qualification on type result with GCC 4.8 only
by Mateusz Loskot 28 Apr '19

28 Apr '19

Hi, (initially posted to https://lists.boost.org/boost-users/2019/04/89778.php) I prepared a lenghty MWE which reproduces my problem with type manipulation using MP11 that for some reason looses const-qualification on a ::type result Here it is at https://godbolt.org/z/eCsakP and copied below. I hope the XXXXXX comments make sense and important static assertions in the main() at the bottom explain what is the expected result. ``` #include <boost/mp11.hpp> #include <cstdint> #include <type_traits> namespace mp11 = boost::mp11; template <typename BitField, int FirstBit, int NumBits, bool IsMutable> struct bit_range_reference { /* long definition, irrelevant */ }; template <typename BitField, typename FirstBit, typename NumBits> struct bit_range_reference_type { using type = bit_range_reference < BitField, FirstBit::value, NumBits::value, true > const; // XXXXXX Why this const gets lost with GCC 4.8 XXXXXX }; template <typename BitField, typename RangeBitSizes> class bit_range_reference_list { template <typename FirstBit, typename NumBits> using reference_type = typename bit_range_reference_type < BitField, FirstBit, NumBits >::type; // XXXXXX Should carry the const, shouldn't? GCC >4.8 do. // If RangeBitSizes is mp11::mp_list_c<int,7,7,2> // then first_bit_list will be mp11::mp_list_c<int,0,7,14,16> using first_bit_list = mp11::mp_fold_q < RangeBitSizes, mp11::mp_list<std::integral_constant<int, 0>>, mp11::mp_bind < mp11::mp_push_back, mp11::_1, mp11::mp_bind < mp11::mp_plus, mp11::mp_bind<mp11::mp_back, mp11::_1>, mp11::_2 > > >; static_assert(mp11::mp_at_c<first_bit_list, 0>::value == 0, "first bit must be 0"); public: using type = mp11::mp_transform < reference_type, mp11::mp_pop_back<first_bit_list>, RangeBitSizes >; }; using reference3_list = typename bit_range_reference_list < std::uint8_t, mp11::mp_list_c<int, 3> >::type; int main() { using r1_t = mp11::mp_at_c<reference3_list, 0>; using r2_t = bit_range_reference<std::uint8_t, 0, 3, true>; using r2c_t= bit_range_reference<std::uint8_t, 0, 3, true> const; //#if defined(__GNUC__) && (__GNUC__ == 4) // GCC 4.8 compiles, later versions of GCC fail to compile static_assert(std::is_same<r1_t, r2_t>::value, "GCC says r1_t is const-qualified"); //#else // GCC 4.9, 5, 6, 7, 8 versions compile, GCC 4.8 fail to compile static_assert(std::is_same<r1_t, r2c_t>::value, "GCC says r1_t is NOT const-qualified"); //#endif } ``` To summary, I expect this to yield true: std::is_same < mp11::mp_at_c<reference3_list, 0> bit_range_reference<std::uint8_t, 0, 3, true> const > I got this confirmed by all GCC versions but GCC 4.8. (clang and MSVC also seem to agree with the GCC >= 4.9) Is mp11::mp_transform loosing const-qualification or have I made a mistake somewhere? I'm using Boost.MP11 from Boost 1.70 and from current develop branch Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 3

[endian] Request for comments
by Peter Dimov 28 Apr '19

28 Apr '19

There are two things that I suspect need to be fixed in Boost.Endian, but the changes are breaking. 1. endian_arithmetic<...> derives publicly from endian_buffer<...>. Intuitively, this inheritance relationship doesn't seem right, and it prevents endian_arithmetic from being a C++03 POD, due to having a base class. 2. the data() member function returns char const*. This type is strongly associated with null-terminated strings, and as such, using it for the underlying bytes of the endian object seems error-prone. I'd much prefer to return `unsigned char const*` from data() (although in C++17 `std::byte const*` might be even better.) I can't however estimate with any certainty whether the (mostly aesthetic) benefit of these changes would outweigh the users' annoyance from their code being broken for no strong reason. Comments?

4 3

CMake, modular Boost, and other stories
by Mike 27 Apr '19

27 Apr '19

Coming at this from a different angle: It might make sense to reserve find_package(Boost_foo) for libraries that directly support installation from cmake. Not sure if such a split is a good idea, but I wanted to put it up for consideration. Best Mike

3 3

PartIcpation in Boost
by Edward Diener 27 Apr '19

27 Apr '19

For personal reasons I will not be able to participate in Boost as I have in the past, which means I will no longer be able to be part of CMT. I will continue to maintain the libraries I created for Boost, tti and VMD, as well as maintaining the preprocessor library created by Paul Mensonides. This means that I will not have the time or the will to be involved with other libraries any more, except on the most general level of discussion. For what it is worth I think that Cromwell Enage should become the maintainer of the Parameter library. I have not, and still do not understand, why when talented C++ programmers are willing to contribute heavily to Boost they are not encouraged and supported more. But this is not my problem. For those who are interested, the experimental C++ standard preprocessor which had been added for VC++ in VS2017 via the '/experimental:preprocessor' switch is still supported in VS2019, although not documented anywhere in the official VS2019 docs. Ths VC++ experimental preprocessor is fully supported in Boost PP and Boost VMD. Unfortunately this preprocessor can not pass all the Boost PP tests, although it has gotten a little better in VS2019 from VS2017. I posted bug reports in Microsoft's bug reporting system regarding its bugs. I have not bothered to test it with the VMD tests, since if it can not pass all the PP tests it is not going to pass the VMD tests. Also while clang on Windows, whether targeting gcc or VC++, passes all the Boost PP tests it fails to pass the VMD tests with lots of errors, seemingly because it is running out of memory ( ? ). I have not bothered reporting this to clang, since my previous experience has shown me that they are clearly not that interested in their Windows implementation. Both gcc on both Linux and Windows, and clang on Linux, pass all the Boost PP and VMD tests. Of course you can try all this out for yourself if you are interested. Edward Diener

3 2

Re: [boost] CMake, modular Boost, and other stories
by Mike 27 Apr '19

27 Apr '19

> +1. Aside from the other benefits mentioned: What benefits exactly? I don't think anyone has mentioned any benefits of dropping the second form at all at all. This isn't an "either or" question - currently both versions are supported. So why exactly should one be dropped? We have talked a lot about Modularization, but little about the original question. Best Mike

1 0

CMake, modular Boost, and other stories
by Peter Dimov 26 Apr '19

26 Apr '19

It's been quiet lately, so it must be time for another CMake discussion. As you know, Boost 1.70 installs CMake configuration files on `b2 install`, and we've started to receive feedback, some of which more interesting than what doesn't work. At present, `b2 install --with-filesystem` for example installs a configuration file boost_filesystem-config.cmake, which enables CMake users to issue the command `find_package(boost_filesystem)` and then use Boost.Filesystem. This mimics what an ordinary, independent library that happened to be called "boost_filesystem" would do. It also installs an umbrella BoostConfig.cmake file, which enables the alternative use of `find_package(Boost COMPONENTS filesystem)`, which treats Filesystem as a component of the package Boost, rather than as a standalone library. This is compatible with the existing, pre-1.70 use of FindBoost.cmake to locate Boost from CMake. Brad King (from Kitware, who should know) argues that installing separate configuration files for all the libraries is wrong. He says that the preferred practice is to only support the second use, with Boost as the package, and the libraries as components, not accessible as packages on their own. (The discussion is here: https://gitlab.kitware.com/cmake/cmake/issues/19186) The reason I went with installing separate configuration files was that I expected that (a) this would be our preferred future approach when, or if, we switch to building with CMake and (b) even if not, this seemed like a step in the right, "modular", direction where libraries are treated as independent rather than parts of the monolithic package Boost. I'm having second thoughts though. It looks to me that Brad is right, and that the various library configuration files should be implementation details of a single Boost package (in the CMake sense) and not be user-visible. That is, only support find_package(Boost COMPONENTS filesystem) and drop find_package(boost_filesystem) Thoughts?

7 11

[build] b2 help moving disjoint_sets
by James E. King III 26 Apr '19

26 Apr '19

I have merged disjoint_sets into boostorg/graph locally and submitted a pull request for it (https://github.com/boostorg/graph/pull/169) The build jobs are failing however, due to disjoint_sets already existing and already having links: https://ci.appveyor.com/project/jzmaddock/graph/builds/24131163/job/uguk1li… b2 headers Performing configuration checks - default address-model : 32-bit - default architecture : x86 - symlinks supported : yes error: Cannot create link boost\pending\detail\disjoint_sets.hpp to libs\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, libs\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. Command exited with code 1 This happened for me locally when I did the work, so I removed it from the superproject locally, and deleted disjoint_sets locally. Any thoughts on how I can tell the build to ignore disjoint_sets so it can install the headers from the new location and complete? This is a temporary situation until the superproject is updated, but the superproject cannot be updated until the code is merged into graph, and the builds are all failing so I cannot prove to the graph maintainers that the pull request is viable. The only way I can see around this is to rename the disjoint_sets headers from pending and into graph, and then fix up graph and graph_parallel, but my intention was to just merge the header into graph, not to change the location of delivered headers. That said, getting something out of pending is always a good thing. Any other ideas? Thanks, Jim

2 1

Making two Boost libraries interoperate
by Andrzej Krzemienski 26 Apr '19

26 Apr '19

Hi Everyone, Somewhat in connection with the discussion about modularizing Boost libraries, we had a certain conceptual problem recently about providing a customization code that allows Boost.Serialization library to serialize Boost.Optional. Such customization requires some code to be written (template specializations provided). Conceptually, such customization code does not belong to Boost.Serialization: we do not expect that Boost.Serialization provides specializations for every library that someone might ever want to serialize. It would also require the maintainer of Serialization to keep track of the implementation of Optional. However, it also does not belong to Boost.Optional: we do not expect that Boost.Optional provides customization points for every framework out there that the users may want to ever use. It would also require the maintainer of Optional to keep track of the implementation of Serialization. However, it is a natural expectation of a Boost user that if the library offers two components they should just smoothly inter-operate with one another. We could provide a small module Serialization-Optional-interop, but that would require many such components to exist and be maintained by someone. I would like to obtain some guidance on how to address such issue. The same problem must already be present between other Boost libraries. Maybe this has been already brought up, and we have a policy for solving this problem somewhere? Regards, &rzej;

10 23

Google Summer of Code slots
by David Bellot 24 Apr '19

24 Apr '19

Dear Boost community, Google has allocated 11 slots for our summer students this year. It's a great news. It means that 11 brilliant students will have the opportunity to work full-time with us and contribute to our libraries. The selected students will be announced soon. I'd like to thank all the mentors for their hard work in preparing the proposals and helping the students to candidate. And of course, a big thank you to Google for supporting open source every year. Best regards, David Bellot

1 0

undefined behavior in Boost.Program_Options
by Chris Rorvick 24 Apr '19

24 Apr '19

I am seeing my GCC ubsan builds littered with "downcast of address xxxxxxxx which does not point to an object of type 'holder'" errors [3] coming from Boost.Program_options (Boost 1.69). The issue has been documented in various places [1][2] but I do not see anything on the mailing list in recent months; apologies if I have missed something. A workaround is proposed on the StackOverflow post [1]. Does anyone have any thoughts on this? Many thanks! Chris [1] https://stackoverflow.com/questions/38987728/why-does-boostany-exhibit-unde… [2] https://github.com/boostorg/program_options/issues/76 [3] .../boost/boost/any.hpp:249:17: runtime error: downcast of address 0x602000053610 which does not point to an object of type 'holder' 0x602000053610: note: object is of type 'boost::any::holder<std::string>' 6f 00 80 67 d0 91 ec 88 fe 7f 00 00 68 33 09 00 40 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'boost::any::holder<std::string>' #0 0x7ffe8df13e3d in boost::program_options::typed_value<std::vector<std::string, std::allocator<std::string> >, char>::xparse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&) const (redacted+0x28be3d) #1 0x7ffe88bb0cd5 in boost::program_options::value_semantic_codecvt_helper<char>::parse(boost::any&, std::vector<std::string, std::allocator<std::string> > const&, bool) const (.../libboost_program_options.so.1.69.0+0xdacd5) #2 0x7ffe88ba9193 in boost::program_options::store(boost::program_options::basic_parsed_options<char> const&, boost::program_options::variables_map&, bool) (.../libboost_program_options.so.1.69.0+0xd3193) #3 0x7fff0b727dbf in rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map>::prepare(int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&) (redacted+0x448dbf) #4 0x7fff0b755e80 in int generic_wrapper<std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> >, rdx::Function<int (boost::program_options::variables_map const&), 56u>, rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map> >(int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&, rdx::Function<int (boost::program_options::variables_map const&), 56u> const&, rdx::launch::OptionsWrapper<boost::program_options::options_description, boost::program_options::variables_map>&) (redacted+0x476e80) #5 0x7fff0b76593c in redacted(std::string const&, int, char**, std::vector<int (*)(boost::program_options::options_description&), std::allocator<int (*)(boost::program_options::options_description&)> > const&, rdx::Function<int (boost::program_options::variables_map const&), 56u> const&) (redacted+0x48693c) #6 0x95c21d in main (redacted+0x95c21d) #7 0x7ffe82fb83d4 in __libc_start_main (/lib64/libc.so.6+0x223d4) #8 0x963523 (redacted+0x963523)

3 2

Re: [boost] CMake, modular Boost, and other stories
by Mike 24 Apr '19

24 Apr '19

> Hmmm - so no boost library should include any > other boost library? DoesÂ that seem a good idea? Please don't put words in my mouth. I didn't say that and you know it. But the dependency graph could easily be significantly simplified once c++03 is no longer a concern. Again: I'm talking about the future, not the current state. Just an example: [1]Boost.TypeErasure depends on [2]Boost.Thread(and all that entails), just because somewhere in its bowels it needs a mutex. > It's always been good practice to notÂ repeat/copy > functionality in one library into another. Not always. A recent example I stumbled over: Boost.Signal2 depended on boost multi index (which itself depends on a lot of other libs) because it reused it's scope guard implementation (IIRC about 50 lines of straight forward code). Tying yourself to another library for something trivial like that should not be a no-brainer. > But what is really needed - and it may already exist > in BCP but hasn'tÂ been promoted is a simple tool: > a) start with one's application > b) run the app through a tool which recurrsively > reads headers > c) and creates a list of all headers needed > d) extract library names from that list > e) add the git repo of those libraries to my apps > project. So boost should not only get its unique build system, but also its unique dependency management tool? I can tell you as a user: Thanks but no thanks. Also: Didn't you forget source files somewhere in there? What about tests? Bottom line: If boost as a whole was developed as a single project with some coordinated devlopment goal and strategy , it would make sense to distribute it as a single package/framework and a single cmake config file. It seems to me however, that it is more a (huge) collection of independently developed libraries, so I think it is more appropriate to treat them as such, even if there is a huge amount of coupling between them. Am 23.04.19, 23:56, Robert Ramey via Boost <boost(a)lists.boost.org> schrieb: On 4/23/19 2:28 PM, Mike via Boost wrote: > I for one very much hope that boost (at least the libraries that > are actively maintained) will become less coupled > in the future, such that when I just want to use > library X, the rest of boost doesnʼt come as a > dependency with it. Hmmm - so no boost library should include any other boost library? Does that seem a good idea? Itʼs always been good practice to not repeat/copy functionality in one library into another. Iʼve said it many times before so I wonʼt make a big deal about it here. But what is really needed - and it may already exist in BCP but hasnʼt been promoted is a simple tool: a) start with oneʼs application b) run the app through a tool which recurrsively reads headers c) and creates a list of all headers needed d) extract library names from that list e) add the git repo of those libraries to my apps project. I donʼt seen any way to get around this. And util we can easily do this - boost will not be modular. Robert Ramey _______________________________________________ Unsubscribe & other changes: [3]http://lists.boost.org/mailman/listinfo.cgi/boost References 1. http://Boost.TypeErasure/ 2. http://Boost.Thread/ 3. http://lists.boost.org/mailman/listinfo.cgi/boost

6 5

[doc][geometry][gil][signals] Broken links for Boost 1.70
by Mateusz Loskot 24 Apr '19

24 Apr '19

Hi, On https://www.boost.org/doc/libs/1_70_0/ links to these documentations are broken: https://www.boost.org/doc/libs/1_70_0/libs/geometry/index/doc/html/index.ht… https://www.boost.org/doc/libs/1_70_0/libs/geometry/extensions/doc/html/ind… https://www.boost.org/doc/libs/1_70_0/libs/gil/doc/html/index.html https://www.boost.org/doc/libs/1_70_0/libs/signals/ Could anyone help to identify what is going wrong with those and how to fix it? p.s. I considered posting to boost-docs but that list seems inactive. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 5

CMake, modular Boost, and other stories
by Mike 23 Apr '19

23 Apr '19

I'm very much in favor of separate packages. James is right, that - at the moment - most boost libraries are so tightly coupled that they can't really be treated as separate libraries, but when changing things it is just as important to ask, "Where do you want to go?" as "where you are now". I for one very much hope that boost (at least the libraries that are actively maintained) will become less coupled in the future, such that when I just want to use library X, the rest of boost doesn't come as a dependency with it. It also fits the management structure (or rather the lack thereof) much better. Also, the mechanisms for modular boost distributons already exist through e.g. vcpkg and conan, so I don't see the problem in also providing independent cmake configfiles. Finally: About how many libraries are we talking here anyway? Only the compiled ones get their separate config file - correct? Best Mike

3 2

[GSOC2019][Boost.uBLAS]
by swornim baral 23 Apr '19

23 Apr '19

Hi List, I realize the deadline has passed for seeking a mentor for GSOC, and I apologize for the delay in initiation. I came to know about the program two weeks prior to the deadline, and started working on completing my proposal and competency test prior to finding any mentors. However, I am still very much interested in working on the project of adding a new numerical and multi-linear algebra algorithm to Boost.uBLAS library. I would love to work on the algorithm for calculating Kronecker and Hadamard product with the guidance of a potential mentor. Since I submitted the proposal in a hurry and without any discussion with a mentor, I could not include specific implementation details in my proposal. Below is the link to my final proposal that I submitted for the GSOC 2019. I would really appreciate any feedback on the proposal, competency test and suggested reading materials to get a head start on implementing the algorithm from any interested mentors. https://drive.google.com/open?id=1saUedBfMCOpmVqQfn1a3YcfPtjPYLeDC . Sincerely, Swornim baral

1 0

Re: [boost] CMake, modular Boost, and other stories
by Peter Dimov 23 Apr '19

23 Apr '19

> Mike wrote: > > > Finally: About how many libraries are we talking here anyway? Only the > > compiled ones get their separate config file - correct? > > ~30-40 at last count. Yes, at the moment. More like 50. Some libraries install more than one.

1 0

[variant2] Formal review
by Bjorn Reese 20 Apr '19

20 Apr '19

I. DESIGN --------- The main design decision of Variant2 is the never-empty guarantee, which is relevant when replacing the value of a variant. This is done without overhead if the alternative types are "well-behaving"; if they are not, then Variant2 falls back to using double storage. This is a major difference to: * std::variant which enters an invalid (valuless_by_exception) state. While that may be appropriate for some use cases, there are others where it is not. For instance, the variant may be used for a state machine where the alternative types are function object types to be invoked when events arrive. Having a valueless state is the wrong choice for this use case. * Boost.Variant which uses a temporary heap object instead. Avoiding this internal heap allocation is sufficient grounds for another never-empty variant type. In time critical applications heap allocation not only introduces indeterministic timing, but may also incur priority inversion due to thread synchronization within the heap allocator. Variant2 has several ways to ensure the never-empty guarantee: V1. If all alternative types have non-throwing assignment, the variant cannot fail during re-assignment. V2. If an explicit null state is available, then this is chosen on re-assignment error. This is similar to std::variant, except is is opt-in. V3. If one of the alternative types has a non-throwing default constructor, then this is chosen on re-assignment failure. V4. Otherwise, the variant will remain it its old state (due to double storage) if re-assignment fails. Criterion V3 is possibly surprising because the variant may change to another type not anticipated by the user. This should be opt-in instead (e.g. using a tag.) I am missing a function to get the index of a type to work with the index() function. Something similar to holds_alternative() but that returns the index instead of a boolean. This useful in switch statements, when we want to avoid visitors for some reason: variant<int, float> var = 1; switch (var.index()) { case index_of<int>(var): /* Do int stuff */ break; case index_of<float>(var): /* Do float stuff */ break; } It would also be beneficial for performance reasons to add accessors that have a narrow-contract, similar to relaxed_get() in Boost.Variant. The implementation is already there (detail::unsafe_get.) 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. II. IMPLEMENTATION ------------------ The implementation is high quality. Although it does lots of meta-programming, most of the style is simple and easy to follow, especially if you have a rudimentary knowledge of Boost.Mp11. In a few places, like the visit() return type, the meta-programming is more hardcore. variant<T...> defines _get_impl as a public "private" function. This can be made more safe by using detail::unsafe_get instead of _get_impl throughout the code. detail::unsafe_get will continue to call _get_impl, but the former should be made a friend of variant<T...> such that _get_impl can be made private. The other public "private" function, variant<T...>::_real_index(), does not seem to be used and can be removed. The emplace_impl(mp_false, mp_false, ...) contains two distinct cases that depend on a compile time condition. If this is split in two, then the two assert()s can be changed into static_assert()s. The variant_alternative and get functions have a couple of compiler workarounds. The code could be made clearer if the workaround is always used for all compilers. Or does is this related to C++11 constexpr? III. DOCUMENTATION ------------------ The documentation is mainly aimed at experienced users. There is no tutorial for people unfamiliar with variant types, nor is there a design rationale that explains why Variant2 is exists when we already have Boost.Variant and std::variant. The reference documentation is adequate, although a bit terse. IV. MISC -------- Having written my own variant class (that has a maximum size, and any type exceeding the limit is allocated on heap) puts me in a good position to assess Variant2. I was also the review manager of Boost.Mp11 upon which Variant2 is built. I have spent 5-6 hours reading documentation, reviewing the code, and writing small test programs. V. VERDICT ---------- Variant2 fills a hole not covered by Boost.Variant and std::variant. I vote to CONDITIONALLY ACCEPT Variant2 into Boost, provided that the following change be made: 1. The selection of an arbitrary non-throwing type in case of an re-assignment failure (criterion V3 in the DESIGN section above) should be made optional. By default it should use double storage in this case. I would furthermore like to see improvements to the documentation, as well as the index_of/safe_get functionality, but neither is a requirement for acceptance. I have not reviewed expected<T, E...>.

11 29

[boost-ci] Build failures for repositories using boost-ci
by James E. King III 19 Apr '19

19 Apr '19

Recent changes to boost have exposed some shortcomings in the boost-ci infrastructure, specifically the use of CXXFLAGS as a variable to hold b2-specific "cxxflags=" content is now getting passed through to the bootstrap build and going to the compiler, and failing. I'm aware of the issue and I am working on a fix that will be backwards compatible with existing Travis CI scripts that use boost-ci to drive their builds. There may also be changes for Windows, but I haven't looked at that yet. This affects the majority of the CMT repositories as well as date_time, format, uuid, function, move, and signals2, and possibly others. More information to follow... - Jim

1 1

[serialization] clarify in doc on overview that library does not aim for inter-process communication nor for backward compatibility
by rafalcpp＠peerfreedom.org 18 Apr '19

18 Apr '19

Hello, Some developers expect archiving or serializing libraries to be backward compatible, for example if I simply save vector<string> to a JSON, then files written from program with more modern json library will be readable on older one and vice-versa. Boost serialization is instead rather intended to read files created by same program with same boost version (or read it on a more recent, but not on older, version of boost). Could we clarify this with a warning on the Overview page? Perhaps something along this lines: " Warning: please note that the format version may change with boost.archive library versions, an old program may not be able to read a format that was designed after it was build. Explanation: some archive libraries offer long lasting forward and backward compatibility of the archived data. For example if your program saves list of book titles into a JSON file, then if your main program itself does not change you can expect to always be able to load that json file - even when loading it on old version of JSON library while archive was saved on a very new one. This is however *not* the case for this boost archive library (at least for the default archive classes) - here even if your main program stays the same then archives written on one using more recent libboost might be unreadable on ones using older libboost. This also means that communication between users (e.g. over Internet) by exchanging archives created by this library will not work in case if users build the program on their own and build it against different versions of boost. Although, a work around exists in form of including specific version of boost serialization library, and freezing that version, in your program, if you are willing to stick to one version of this module. " Please correct if there are any mistakes (for example if that is possible in some special way).

2 1

[variant2] Review
by Jan Herrmann 17 Apr '19

17 Apr '19

Hello, I looked at the review, at the code and some time ago I tried to implement my own variant. In my opinion in variant2 the individual parts are more worth than the whole. Most implementation details would be of great use for implementing variants with a differnt trade-off. Hence the library ought to be split into several independend parts: * a typing switch * a variadic union * an extendable visitation mechanism * a variant view * related type traits * several implementation of a concrete variant 1. A typing switch The typing switch would be provide a litle bit more than (and can be implementated with help of) mp_with_index. The following pseudo code shows the implementation idea: template<size_t MaxIndex, class Function, class Cast, class Object> constexpr decltype(auto) typing_switch(size_t index, Function fun, Cast cast, Object obj) { return fun(cast(integral_constant<size_t, index>{}, obj)); } The object is a variant and the cast transfroms this special variant to a concrete value (with type). The function is provided by the variant user. The visit function (line 1732) would become something like this: template<class Variant> struct variant_cast { template<class Index> constexpr decltype (auto) operator()(Index, Variant& V) { return unsafe_get<Index::value, V>(); } }; template<class Fun, class Variant> constexpr decltype(auto) visit( F&& f, V1&& v1 ) { return typing_switch<variant_size<V1>>(v.index(), f, variant_cast<V1>, v1); } A simplified deserialisation can be implementated as follows: template<class Types> struct index_to_type { template<class Index> constexpr decltype (auto) operator()(Index, std::nullptr_t) { return mp_identity<mp_at<Types, Index>>{}; } }; template<class Variant, class Archive> Variant deserialize(Archive& ar) { size_t index; ar >> index; Variant f = [&ar](auto type) { decltype(type)::type concrete_element; ar >> concrete_element; return Variant{std::move(concrete_element)}; }; return typing_switch(index, f, index_to_type<Variant>{}, nullptr); } With help of this function an implementation of a visitation function is easy. 2. A varidic union Without doubt a type implementing a varidaic union is a building block for almost every variant implementation. It should be part of the public interface, well tested and with a minimal interface (get<i> and emplace<i>) 3. An extendable visitation mechanism This could be used to implement visitation on multiple different variants. It should use visit on one variant as customization point. 4. A variant view (and a mutable variant view) It could have the following form: template<class... T> class variant_view { void* value; size_t index; public: /* visit ... */ }; It is a little bit like folly/DiscriminatedPtr.h (https://github.com/facebook/folly/blob/master/folly/DiscriminatedPtr.h) but without platform specific code. It can be used for functions which take variants as a const references (or in the mutable form as variants which can change the value but not the actual type). It can be constructed from corresponding variants, values (which are part of T...) and other variant_views. As long as it is constructed from a variant implemented with the variadic union the process can be simple: all members of a union have the same address as the union and the index is equal. For special cases the process can be more complicated. For other variant_views the transformation can be implemented as a runtime lookup in an array and for simple values it is simple. A variant_view can for example be used for functions accepting const references like output and serialisation, or for referencing "polymorphic" objects like nodes in ASTs. 5. Related type traits Meaningfull type traits which can be used in one variant have a good chance be be used in a related one. If one variant want to static assert in case void is one of its types the logic is probably usefull for others. They should be collected. 6. Several implementation of a concrete variant This is the place for variant2. With this building blocks it should be simpler to implement a custom variant. Now lets think of a few use cases: A class contains 3 variants each containing only a few "small" types. Instead of using 3 variants it could pack all indices into one int and construct variant_views as needed. This can reduce the size of the class and saves memory bandwidth. Editing of variants would be of course more complicated. A variant containing a few trivial small types which are used in allmost all cases and one type (T_evil) which is used rarely, is big and can throw in certain situation. The soloution can be a normal variant with the exception of storing T_evil as a smart pointer and dereferences it when visited. A variant with allocator support. In case a user has a solution (or idea) for their variant which lives in shared memory a simple blueprint with generic components like varidic union, a typing switch and useable type traits may be of help. I think requirements for different variant types mentioned in the review could be implemented with some well defined basic building blocks. Beside these thougths I looked at the library. expected.hpp: I tried to compile the following file (containing only one non empty line): #include <boost/variant2/expected.hpp> and it does not compile. It should be a self-contained header. Therefore it should be not part of the library. variant.hpp: Personally (in contrast to other reviewers) I would prefer code more structured in different files. In an ideal world there is for every component a single header file (in clean C++ 17) with minimal dependencies which directes for compiler (and version) specific stuff to a different header. For the future it would result in source code written in newest standard without disturbing influence from ifdefs caused by old buggy compilers. The source has more than 1800 lines with only a few comments, short (1 char) names and very long lines (200 chars and more). For me it is not easy to read (after clang-format it is 2030 lines). Variant alone has more than 450 lines of code. With more shorter files the connection of (and dependencies among) the components would be more visble. I started at the begining of the file and searched for a testcases for monostate and I didn't found one. There are a few testcases inside variant_valueless.cpp which use monostate but none which test it directly. Next variant_size. There are testcases but most deal with variants of type 'variant<> const', 'variant<void>' and the like. Declaring variables of these types results in compile time errors. It is not wrong std::variant gave me the same result, but it is a kind of strange that most tests are implemented in terms of variants wich are ill-formed. On the other hand there are no tests which do not compile. These are two example which should not compile. The template detail::variant_alternative_impl looks like something which copies const, volatile and references. Is there a difference to copy_cv_ref at the end? Could it be used? At the end of the file the comparison is implemented. But operator!= is not implementated in terms of operator== and operator<= and others not in terms of operator<. In case there is a reason for it documentation would be nice. Summarized I think variant2 should NOT be part of boost. I think the focus should be more on reusable components and better documented code. I think most of the code could be very usefull with more descriptive names and test. Regards Jan Herrmann

7 10

[variant2] Review of Variant2 started today : April 1 - April 10
by Michael Caisse 16 Apr '19

16 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> The master branch will be stable for the review: <https://github.com/pdimov/variant2/tree/master> Find the documentation here (also stable during the review): <https://pdimov.github.io/variant2/doc/html/variant2.html> Note: The repository contains an expected implementation also; however, that is not being considered in this review. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Variant2 as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

8 20

Mother of all Variants
by Nikita Kniazev 16 Apr '19

16 Apr '19

I do not see any progress in the never-ending never-empty vs everything discussion. It looks like an argument about tastes, and I see no room for compromise here. Number of examples for any point of view is also close to zero. Instead of saying that you would like more one or another, just implement it, and let the user decide which one to use. Or, at least, make a poll that will show needs in promoted by you implementation instead of forecasting from your big, but personal experience. A policy-based design is good in theory, but what in practice? In practice, you want one person to make and maintain bunch of different variants, which you, most likely, will never use, but users, most likely, will have nightmares in using it, especially in API, due to signature verbosity. More code will hurt preprocess and compile times for sure. What surprises me a lot that there was not much attention to the fact that because of number 2 in the name users will come and will ask about it. Do I need an upgrade? Is `variant` deprecated? Is `variant2` an improved version of `variant`?

1 0

GSOD
by Siddhartha Sen 16 Apr '19

16 Apr '19

Any information on how and where to apply for GSOD?

2 1

[variant2] Andrzej's review
by Andrzej Krzemienski 16 Apr '19

16 Apr '19

Hi Everyone, I recommend that variant2 should be REJECTED in its current shape. The main (and only) reason for rejection is the never-empty basic exception-safety guarantee offered and endorsed by the library. I have serious concerns that by adding it into Boost we would be leveraging the concept that is bug prone and encouraging bad habits. I have expressed my concerns in detail in another mail. I find this to be in contrast with what I perceive as goals of Boost. It is my understanding that the never-empty basic guarantee is the core of the library therefore the conditional acceptance would not work. My recommendation would be different if the library dropped the goal of providing the never-empty guarantee, or if it provided a strong guarantee in the cases where assignment emplacement required to change the alternative. I honestly appreciate the work Peter has done to provide this library, but I strongly disagree with the primary design decision. If the library is still accepted I recommend the following things: 1. Call it something slightly different so that at least namespace name clearly indicates that it is not an "improved std::variant" or "improved boost::variant" but just another offer in the market with different design choices in the design space: maybe ne_variant (for "Never Empty") or si_variant (for "Strong Invariant"), or even pdimov_variant (for "Perfectly Defined Invariant Model Of Variant"). 2. Drop the implementation of std::expected. It does not fit into the same library even if 90% of the implementaiton is shared. Propose a second library even if what it does is to #include the variant. 3. Move functions unsafe_get() from namespace detail and make them part of the official interface. You need to use them yourself in the implementation of visit() because otherwise you could not implement it efficiently. They are part of the minimum efficient base interface. Even if required very occasionally. 4. Provide a 2 minute introduction to the library for the newbies. We do not need a full tutorial. A link to someone else's description will do, but a short introduction I think is a must. I offer to help write one. 5. Provide a design rationale explaining why the never-guarantee is offered at all and why in this way. Why you are disregarding the design choices of boost::variant's never-empty guarantee. Also provide a detailed description on which algorithm is chosen under what circumstances and what it does to provide the guarantee. Now, to review questions: - What is your evaluation of the design? As noted, I strongly disagree with the main design choice of the library: the never-empty guarantee. I see no positive value, I see negative value. This aside, I do not see much design choices here: it is a quite small vocabulary type. - What is your evaluation of the implementation? Of all reviews I have participated in I have never found it so easy to understand the implementation. I find it very clean and short. I appreciate that it is a single header library. I can just copy the content of the file and test it in WandBox. Also the implementation is a very good practical tutorial on mp11. Peter already wrote good tutorials on mp11, but here for the first time I have seen it used for something that I consider a real life application. The implementation of variant looks so simple with mp11. - What is your evaluation of the documentation? The reference part meets the high standards of Boost. I am missing even a short introduction that would give us the motivating example. Some have said that it is enough to say "find the tutorial on std::variant". I disagree: there is no good introduction to variant, and I think Boost libraries have a good history for providing a good problem domain description apart form the implementation. I also think that given the controversies around the never-empty guarantee the design choice requires a detailed information in the docs. - What is your evaluation of the potential usefulness of the library? Given that I find std::variant design superior, I suspect this library would be useful in environments that cannot afford to use C++17 yet. It has advantages over boost::variant. It has cleaner implementation. boost::variant is giving me lots of warnings in clang-tidy. I expect these to be gone in variant2. Also the trade-offs made in double buffering may be superior to those in boost::variant: no memory allocation, no additional potential reason for throwing. - Did you try to use the library? With which compiler(s)? Did you have any problems? I tried to break the library with nasty cases in various clang and GCC versions. I reported some minor bugs over GitHub. Peter is quickly addressing them. The library does not compile in GCC 8.2 and higher in C++17 mode due to some bug in GCC. This is already tracked as issue. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have spent a number of evenings reading the docs, the sources, playing with the library, debugging, discussing the design in the mailing list. I also followed the discussion in the C++ Standards Committee, where similar issues with never-empty guarantee were discussed. - Are you knowledgeable about the problem domain? I have a lot of experience with different implementations of `optional`: I am maintaining the boost version, I have provided the wording and the design for the std version and provided the reference implementation thereof (at https://github.com/akrzemi1/Optional/) which turned out surprisingly popular. Optional needs to solve similar problems in the implementation: manually managing a raw buffer or a union, and has similar problems with exception safety guarantees. However it does not need to address the never-empty guarantee issue. I also use a lot of boost::variant at work. Finally, I want to thank Peter for writing this library and submitting it for review. The review itself was very instructive. Regards, &rzej;

10 19

[doc][test] change log broken from release notes
by Raffi Enficiaud 15 Apr '19

15 Apr '19

Hi, The link to the change logs is broken from the 1.70 release note (points to https://www.boost.org/users/history/libs/test/doc/html/boost_test/change_lo… instead of https://www.boost.org/doc/libs/1_70_0/libs/test/doc/html/boost_test/change_… ) I believe I used the same way I did for the past releases. How can I correct this? Thanks, Raffi

1 0