- Boost-users - lists.preview.boost.org

Program Options MacOS Error
by Michael Chiu 10 Sep '19

10 Sep '19

Hi All, I was trying to use boost program options to capture a std::string like the examples in the documentation. However I keep getting the error: libc++abi.dylib: terminating with uncaught exception of type boost::wrapexcept<boost::bad_any_cast> when i try to retrieve the value from the valuemap, i.e. vm["source"].as<std::string>(); The code that I have (which right now is essentially the tutorial example) runs fine on linux but has the above error on macos. Am i doing something wrong or is this a genuine platform specific bug? Sincerely, --Michael

1 0

Re: [Boost-users] xlcpp: use of undeclared identifier 'decltype' used in boost/thread/lockable_traits.hpp
by Roy Musselman 10 Sep '19

10 Sep '19

Greetings, While attempting to build boost 1.70.0 for IBM Power9 using the IBM XL compilers using the SPACK tool, the following errors occur repeatedly for every header file that eventually includes boost/thread/lockable_traits.hpp In file included from ./boost/thread/lock_types.hpp:14: ./boost/thread/lockable_traits.hpp:157:11: error: use of undeclared identifier 'decltype' decltype(void(boost::declval<T&>().lock())) ^ ./boost/thread/lockable_traits.hpp:165:11: error: use of undeclared identifier 'decltype' decltype(void(boost::declval<T&>().unlock())) ^ ./boost/thread/lockable_traits.hpp:173:11: error: use of undeclared identifier 'decltype' decltype(bool(boost::declval<T&>().try_lock())) ^ These errors could be resolved if the -std=c++11 compiler option is used. Attempting to use SPACK options cxxflags=-std=c++11 or cxxstd=11 failed as if they were ignored. I was able to work-around this pervasive error by adding the following line to the file tools/build/src/tools/xlcpp.jam flags xlcpp.compile.c++ OPTIONS <cxxstd>11 : -std=c++11 ; Can you update the xlcpp.jam file to support the cxxstd=11 option, similar to what is implemented in pgi.jam? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Roy Musselman IBM HPC Application Analyst at Lawrence Livermore National Lab email: roymuss(a)us.ibm.com

2 3

[asio] writing composed operations example
by Stephan Menzel 03 Sep '19

03 Sep '19

Hi everyone, as a long time asio user I often had needs to wrap up repeating patterns of async calls for re-use. Normally I went for some kind of specialized object that wraps smaller pieces but I recently came across a series of examples which try to explain how own composed operations may be created. https://www.boost.org/doc/libs/1_71_0/doc/html/boost_asio/examples/cpp11_ex… Now, looking at the examples they are of course way over my head but since own composed operations would be very much exactly what I need I thought I'd give it a shot. But as I now look at this example here: https://www.boost.org/doc/libs/1_71_0/doc/html/boost_asio/example/cpp11/ope… I notice something that I hope somebody can explain. In the coroutine implementation it says: delay_timer_->expires_after(std::chrono::seconds(1)); yield delay_timer_->async_wait(std::move(self)); if (error) break; yield boost::asio::async_write(socket_, boost::asio::buffer(*encoded_message_), std::move(self)); I'm puzzled about the double std::move() of self. In the comments above it says that self is a reference to an intermediate completion handler. How can this be moved twice? Can anyone give me hint about what this means? I would also appreciate any hints in general about own composed operations. Perhaps there are other approaches that are a bit less intimidating? Cheers, Stephan

3 3

[MSM] Substatemachine with constructor arguments
by jcbastosportela＠gmail.com 30 Aug '19

30 Aug '19

Hi all, My question regards boost's Meta State Machine (MSM) usage. In my current design of a state machine it would be desirable to pass arguments to the substate machine; this would be done at time of creation of "main state machine". I found something on the documentation close to what I am looking for, however not exactly. State machine constructor with arguments <https://www.boost.org/doc/libs/1_71_0/libs/msm/doc/HTML/ch03s05.html#d0e2502> . This works very well for states, but doesn't work for the substate machine. Fails in compilation with the following log: In the example <https://www.boost.org/doc/libs/1_71_0/libs/msm/doc/HTML/examples/Constructo…> found in the documentation I would changed the *Playing* substate machine to look like: and in creation of the *player* to do something like: See the file attached. msm_substm.cpp <http://boost.2283326.n4.nabble.com/file/t371477/msm_substm.cpp> Is there a way of achieving this? Many thanks in advance. Regards, Joao Portela -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Users-f2553780.html

1 0

Re: [Boost-users] Template specialization for Boost.Polygon
by Bjorn Reese 28 Aug '19

28 Aug '19

On 8/26/19 5:39 PM, Phil Endecott via Boost-users wrote: > Can anyone suggest how I can write my specialisations so that they > are unambiguous? By adding another level of indirection. Create your own trait template. Let both the generalization and your specialization redirect to polygon_traits. Something like this (warning untested code ahead) template <typename T, typename Enable = void> struct my_polygon_traits : public polygon_traits<T, Enable> { }; template <std::size_t N> struct my_polygon_traits<std::array<Point, N>> : public polygon_traits<std::array<Point, N>> { };

4 5

Template specialization for Boost.Polygon
by Phil Endecott 26 Aug '19

26 Aug '19

Dear Experts, This is a question about Boost.Polygon but please keep reading even if you've never used that library as it's really just about how to resolve ambiguous template specialisations. Boost.Polygon has a mechanism by which you can tell it about your own types by specialising templates. I want to tell it that std::array<Point,N> is a polygon, which I try to do like this: template <size_t N> struct geometry_concept< std::array<Point,N> > { using type = polygon_concept; }; template <size_t N> struct polygon_traits< std::array<Point,N> > { ....... }; This doesn't work because of ambiguity between that specialisation of polygon_traits and a default specialization that is in the library itself; the library code looks something like this: template <typename T, typename enable = gtl_yes> struct polygon_traits {}; template <typename T> struct polygon_traits<T, ...some SFINAE stuff.... > { ......... }; If I try to just specialize one size of array it works: template <> struct polygon_traits< std::array<g2i::Point,3> > { ....... }; The error is: test_template_specialization.cc:64:19: error: ambiguous partial specializations of 'polygon_traits<std::__1::array<Point, 3>, boost::polygon::gtl_yes>' boost::polygon::polygon_traits<std::array<Point,3>>::iterator_type i = nullptr; ^ /usr/local/include/boost/polygon/polygon_traits.hpp:100:10: note: partial specialization matches [with T = std::__1::array<Point, 3>] struct polygon_traits<T, ^ test_template_specialization.cc:32:8: note: partial specialization matches [with N = 3] struct polygon_traits< std::array<Point,N> > ^ I have the same issue when I attempt to use a Point class that takes the coordinate type as a template parameter. Can anyone suggest how I can write my specialisations so that they are unambiguous? A complete test program follows. I'm testing with Boost 1.69.0, but I don't think anything has changed in Polygon since then. Thanks, Phil. #include <boost/polygon/polygon.hpp> #include <array> struct Point { int x; int y; }; namespace boost { namespace polygon { template <> struct geometry_concept<Point> { using type = point_concept; }; template <> struct point_traits<Point> { using coordinate_type = int; static inline coordinate_type get(const Point& point, orientation_2d orient) { return (orient==HORIZONTAL) ? point.x : point.y; } }; template <size_t N> struct geometry_concept< std::array<Point,N> > { using type = polygon_concept; }; template <size_t N> struct polygon_traits< std::array<Point,N> > { using coordinate_type = int; using iterator_type = typename std::array<Point,N>::const_iterator; using point_type = Point; static inline iterator_type begin_points(const std::array<Point,N>& p) { return p.begin(); } static inline iterator_type end_points(const std::array<Point,N>& p) { return p.end(); } static inline std::size_t size(const std::array<Point,N>&) { return N; } static inline winding_direction winding(const std::array<Point,N>&) { return unknown_winding; // Hmm. } }; }; }; // namespace boost, polygon int main() { boost::polygon::polygon_traits<std::array<Point,3>>::iterator_type i = nullptr; return 0; }

1 0

Help building one module with cross-compiler
by Adrian C 25 Aug '19

25 Aug '19

Hi, I am trying to build boost module "log" on a raspberry PI as a dependency to another project. The RPI runs out of virtual memory during the build process, although I do limit building to just log (I think it builds some dependencies though). So I decided to cross compile it on a x86 machine with plenty of resources. I followed the instructions and built using: BUILD_CXXFLAGS="-std=gnu++11 -pthread" BUILD_CXX=arm-linux-gnueabihf-gcc ./bootstrap.sh --with-libraries=log --with-toolset=cross-cxx The build fails with the bootstrap.log showing the content below. Your advice is appreciated. thank you ubuntu@ryu:~/arm-toolkit/boost_1_71_0$ cat bootstrap.log######### Using 'cross-cxx' toolset.######arm-linux-gnueabihf-gcc --versionarm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)Copyright (C) 2013 Free Software Foundation, Inc.This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ######arm-linux-gnueabihf-gcc -std=gnu++11 -pthread -DNDEBUG builtins.cpp class.cpp command.cpp compile.cpp constants.cpp cwd.cpp debug.cpp debugger.cpp execcmd.cpp filesys.cpp frames.cpp function.cpp glob.cpp hash.cpp hcache.cpp hdrmacro.cpp headers.cpp jam.cpp jambase.cpp jamgram.cpp lists.cpp make.cpp make1.cpp md5.cpp mem.cpp modules.cpp native.cpp object.cpp option.cpp output.cpp parse.cpp pathsys.cpp regexp.cpp rules.cpp scan.cpp search.cpp strings.cpp subst.cpp sysinfo.cpp timestamp.cpp variable.cpp w32_getreg.cpp modules/order.cpp modules/path.cpp modules/property-set.cpp modules/regex.cpp modules/sequence.cpp modules/set.cpp execunix.cpp fileunix.cpp pathunix.cpp -o b2/tmp/ccFB5qkl.o: In function `(anonymous namespace)::std_thread_hardware_concurrency()':sysinfo.cpp:(.text+0x118): undefined reference to `std::thread::hardware_concurrency()'collect2: error: ld returned 1 exit status

2 3

License Issue with boost_intrusive
by Gerald Wiltse 23 Aug '19

23 Aug '19

During an annual third-party audit of our source code, boost intrusive was flagged as containing unlicensed code. Specifically, there are several pieces of code in this file which are explicitly attributed to external parties on external websites, which still exist and show no license. https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… Original sources: http://stackoverflow.com/questions/11376288/fast-computing-of-log2-for-64-b… http://www.flipcode.com/archives/Fast_log_Function.shtml I don't claim to be a license expert. I've read a lot over the years, but this is the first time that I've actually been between an attorney and a codebase having to figure out practical implications of a scenario like this. I first want to make sure that Boost committee is aware of this situation. Second, I would like to know what the official conclusion would be from the Boost Committee about the license implications in cases like these. Maybe it has come up before and is well established. On the surface, the implications seems ambiguous to me when: DEVELOPER_A takes unlicensed code off the internet, prefixes it with a comment that says "Thanks to DEVELOPER_B ", then prefixes the whole file with a file-level copyright notice that says "COPYRIGHT DEVELOPER_A", and then says it's distributed under BSL-1.0 license, and then the boost team re-distributes the source code. Internally at my company, there was little discussion about it. There is no room for ambiguity, so the directive from management was to delete the file from our SCM system completely and ensure it never is included in our products. VERY fortunately, deleting it doesn't seem to have broken our builds. In future cases like this, that's really not what we want to be doing with your OSS libraries for obvious reasons. So, I'd like to know if there's any chance this situation changes in a future version of Boost (I.E., the code be removed/re-written with clean-room approach, etc). Regards, Jerry Gerald R. Wiltse jerrywiltse(a)gmail.com

2 1

[release] Boost 1.71.0
by Michael Caisse 21 Aug '19

21 Aug '19

Release 1.71.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library (Variant2) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.71.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.71.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse

4 3

[Dll] e0077 with BOOST_DLL_ALIAS
by Sean Farrow 20 Aug '19

20 Aug '19

Hi, I'm getting the following error when using BOOST_DLL_ALIAS to export a function to create a plugin using visual studio 2019 and boost 1.71. This isn't new, just the first time I've noticed it. E0077 this declaration has no storage class or type specifier I've cross-checked this with the example (specifically tutorial 2) to ensure that it wasn't just me. For reference, the offending line in the my_plugin_aggregator.cpp file is: BOOST_DLL_ALIAS( my_namespace::my_plugin_aggregator::create, // <-- this function is exported with... create_plugin // <-- ...this alias name ) Other than suppressing this specific error, is there any other work around given I'm compiling with treat warnings as errors enabled? Any help appreciated as always. Thanks, Sean.

1 0