- Boost - lists.boost.org

[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