April 2019 - Boost - lists.preview.boost.org

CMake Announcement from Boost Steering Committee
by Jon Kalb 13 Aug '24

13 Aug '24

The libraries produced by the Boost community have had a greater impact on the way that the C++ community writes code than any other library implementation. The focus of the Boost community will always be on the libraries, but it is undeniable that we are dependent on and often limited by the infrastructure of our trade. Years ago, the move to Git was contentious; yet, it was required to improve development. In a similar vein our build system has become an impediment for many developers and users, existing and prospective. Therefore, we, the Steering Committee, announce to the Boost community our desire and intent to move Boost’s build system to CMake for users and developers alike. We are soliciting comments and proposals from the community to guide the process and the goals. Our desire is that the community can come to consensus by the end of the calendar year with a vision of supporting users and developers. We understand that the actual process of achieving the end goal will be long, time consuming, and not without its share of conflict. We also recognize that the Boost community is comprised of bright and passionate individuals that are eager to get involved and help get work done. The members of the Steering Committee have been encouraged by the discussions and activity surrounding CMake on the mailing lists over the years and know that many people have voiced visions. We hope that each of you rejoins the discussion to support this initiative and contributes to the common goal of improving Boost’s integration into the broader C++ ecosystem. For the Boost Steering Committee, Jon Kalb, Chair jonkalb(a)boost.org

49 199

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Mother of all Variants
by Robert Ramey 05 Jul '19

05 Jul '19

I'm way out of my depth in the variant discussion. Seems to me it revolves around all the trade offs regarding design choices. Could we perhaps decide not to decide. Suppose we create a type which looks like: template< bool BasicGuaranteeSupported, bool StrongGuaranteeSupported, bool EmptyStateProhibited, bool AssignmentSupported, bool MoveSupported, class T ... > struct mother_of_variants{ // some trivial mp11 code }; Now we could define: using boost_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool true, //AssignmentSupported, bool true, //MoveSupported, >; std_variant, std_optional, std_expect, boost_outcome, etc. would be similarly defined. And some "extras" like no_except_variant, trivial_variant, etc. would be added. and of course my favorite candidate: using safe_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool false, //AssignmentSupported, bool false //MoveSupported, >; In addition, we'd have some type traits: mother_of_all_variants::no_runtime_allocation<mov>; mother_of_all_variants::no_double_instancen<mov>; mother_of_all_variants::is_mother_of_all_variants<mov>; etc. Just think that of all the time we've spent on discussions about optional, expected, std::variant, boost::variant, etc. At this rate, these discussions will keep hounding us forever. Of course I realize that the main purpose of having these variants of variants is to justify the discussions - but perhaps we might be ready for a new topic. Robert Ramey

17 57

Non-ASCII Path Names in Repo
by Tom Kent 25 May '19

25 May '19

In the last few days we've had a non-ASCII path name added to the repo: tools/boostdep/test/utf8-test-ßµ™∃ Which came with commit 8893d1c57951a [1] I noticed this because a python 2 script (calling shutil.copytree) I had running on windows that copied the repo around started to fail. I've long needed to update that script to python 3, and am working on this. However, I wanted to point this out to the list so we could discuss if there are any other ramifications of having a non-ascii path. I vaguely remember some discussion about something like this in the past, but couldn't find it via search. If this is already a settled topic, that's great. Tom [1] https://github.com/boostorg/boostdep/commit/8893d1c57951a4a83705ed203005576…

2 1

Re: [boost] [ Interest? ] [ out_ptr ] Tiny C++ Abstraction for C-Style Output Pointers
by Bjorn Reese 12 May '19

12 May '19

On 06/28/18 21:03, ThePhD via Boost wrote: > out_ptr is a small abstraction for making types such as > std::unique_ptr, std::shared_ptr, boost::shared_ptr, and the upcoming > std::retain_ptr > <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0468r0.html> work > work C-Style output functions as a parameter, addressing the need of > wanting to be able to do "my_c_api_init( foo, bar, &my_smart_ptr );". It's Does out_ptr have other use-cases than C interoperability?

7 14

b2 --layout=versioned compiler tag in library filename
by Paul Harris 06 May '19

06 May '19

Hi guys, In the past, b2 would build libraries named like so: libboost_atomic-gcc48-mt-d-1_60.so (note -gcc48-) I tried compiling Boost 1.66.0 (from boost-git) with gcc 8.3.0, but the library it generates is named: libboost_atomic-gcc-mt-d-x64-1_66.so (note the -gcc-) No compiler version number in the tag... I (and CMake) was expecting it to be named: libboost_atomic-gcc83-mt-d-x64-1_66.so (note the -gcc83-) To build, I did: ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned I then downloaded the 1.70.0 tarball and compiled that, and this time the result was: tar xfv boost_1_70_0.tar.bz2 cd boost_1_70_0/ ./bootstrap.sh --with-libraries="atomic" ./b2 --layout=versioned ls -l stage/lib libboost_atomic-gcc8-mt-d-x64-1_70.so I don't see any documentation around the compiler version tag, what is the current policy? thanks, Paul

5 7

[thread] compiler error gcc 7.3 on cygwin
by James E. King III 06 May '19

06 May '19

Getting an internal compiler error with gcc 7.3 but only on cygwin 64-bit. Jim@pulsar /cygdrive/c/boost/libs/thread $ ../../b2 --abbreviate-paths toolset=gcc cxxstd=11 define=_POSIX_C_SOURCE=200112L define=__USE_ISOC99 threadapi=pthread address-model=64 variant=release -q ... gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o In file included from ../../boost/thread/detail/invoker.hpp:30:0, from ../../boost/thread/future.hpp:31, from ../../libs/thread/test/test_10963.cpp:13: ../../boost/thread/detail/invoke.hpp: In function ‘decltype (*(forward<A0>)(boost::detail::invoke::a0).*boost::detail::invoke::f) boost::detail::invoke(Fp&&, A0&&) [with Fp = void (boost::executors::basic_thread_pool::*)(); A0 = boost::executors::basic_thread_pool*]’: ../../boost/thread/detail/invoke.hpp:102:43: internal compiler error: in gimplify_expr, at gimplify.c:12006 return (*boost::forward<A0>(a0)).*f; ^ Please submit a full bug report, with preprocessed source if appropriate. See <https://gcc.gnu.org/bugs/> for instructions. "g++" -std=c++11 -fvisibility-inlines-hidden -m64 -mthreads -O3 -finline-functions -Wno-inline -Wall -pedantic -fvisibility=hidden -Wextra -Wno-long-long -Wno-unused-parameter -Wunused-function -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DNDEBUG -D_POSIX_C_SOURCE=200112L -D__USE_ISOC99 -I"../.." -c -o "../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o" "../../libs/thread/test/test_10963.cpp" ...failed gcc.compile.c++ ../../bin.v2/libs/thread/test/test_10963_c.test/gcc-7.3.0/rls/cxstd-11-iso/thrd-mlt/vsblt-hdn/test_10963_c.o... If I change the C++ language level to 03 the problem goes away. I also cannot reproduce it on linux with the same version of compiler (but it probably isn't the exact same compiler code). Should I go ahead and file that gcc bug? - Jim

2 1

[variant] Heads-up!
by Antony Polukhin 02 May '19

02 May '19

Hi, I've merged a very cool optimization by Nikita Kniazev into the master branch. From now on boost::variant does pointer stealing for recursive variants. This significantly improves the performance of the variants move constructors. However if you use a variant variable after the std::move for anything except destruction and assignment then you're getting an UB. Beware! -- Best regards, Antony Polukhin

9 25

Re: [boost] [variant] tests failing on master
by Nikita Kniazev 30 Apr '19

30 Apr '19

> boost.variant tests are failing on master. Whatever the bug is, it is also causing my signals2 tests that use variant to fail. Config needs develop to master merge to resolve the issue.

1 0

[variant] tests failing on master
by Frank Mori Hess 30 Apr '19

30 Apr '19

boost.variant tests are failing on master. Whatever the bug is, it is also causing my signals2 tests that use variant to fail. -- Frank

1 0

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