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

singleton.hpp, leak
by Matt Vinson 19 Mar '18

19 Mar '18

Hello,I am using 64-bit, Windows 7, Visual Studio 2017, 15.5.7 on a MFC project. Since updating to 1.66, I think I have leaks traced to singleton.hpp. I put a _crtBreakAlloc = Allocation number and it stops near singleton.hpp.Is it possible this class now has leaks?It true, is there a work around? Any help is appreciated,

2 1

[Asio] How to assign raw sockets (descriptors) to boost::asio::ssl::stream ?
by Dmitriy V 17 Mar '18

17 Mar '18

Hi guys ! I have client server app written on boost::asio. I want to implement updating the server through `execve`. But I don't know how to assign integer socket descriptor (given by streamssl_.lowest_layer().native_handle()) to newly initialized server object after the updating (descriptors strored/restored in shared memory ...) Any help, please ! -- the best regards

2 2

Building Boost 1.66.0 - probable user error
by Larry 16 Mar '18

16 Mar '18

I must be getting old. Building Boost used to be so much easier. I suspect I have missed something in the doc. I downloaded 1.66.0. This is for Win8.1 and MSVC 2017. From a command line bootstrap finally worked to get b2 although there were complaints about some of the options. Running b2 fails. I used to do .\b2 --prefix=xxx toolset=msvc --build-type=complete stage Almost verbatim from the Getting Started doc. stage is not a target is the error. As far as I know the only way to find targets is to wander through .jam files (finding targets was always difficult as far back as 1.27 as I recollect). Any idea what I missed and where? Larry

2 1

[Optional][Variant] Different behavior vs std c++17
by dariomt＠gmail.com 14 Mar '18

14 Mar '18

Hi list, I'm observing different behavior in boost::optional and boost::variant compared to their std c++17 versions. Using Boost 1.64 The following example fails to compile with -DUSE_BOOST using either gcc 7.3 or clang 6.0 #include <boost/optional.hpp> #include <boost/variant/variant.hpp> #include <optional> #include <variant> struct A {}; struct B {}; struct C {}; #ifdef USE_BOOST using V = boost::variant<A,B,C>; using OV = boost::optional<V>; #else using V = std::variant<A,B,C>; using OV = std::optional<V>; #endif OV f(B b) { return b; } Is this difference in behavior expected for such a simple example? Is it possible to improve Boost to make this example compile? Thanks in advance! PS: the Boost only version works in VS2015, not sure why... PPS: Try it in godbolt! https://godbolt.org/g/n4Vbr9 gcc 7.3 says <source>: In function 'OV f(B)': <source>:20:12: error: could not convert 'b' from 'B' to 'OV {aka boost::optional<boost::variant<A, B, C> >}' clang 6.0.0 says <source>:20:12: error: no viable conversion from returned value of type 'B' to function return type 'OV' (aka 'optional<variant<A, B, C> >') return b; ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:796:5: note: candidate constructor not viable: no known conversion from 'B' to 'boost::none_t' for 1st argument optional( none_t none_ ) BOOST_NOEXCEPT : base(none_) {} ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:800:5: note: candidate constructor not viable: no known conversion from 'B' to 'boost::optional<boost::variant<A, B, C> >::argument_type' (aka 'const boost::variant<A, B, C> &') for 1st argument optional ( argument_type val ) : base(val) {} ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:805:5: note: candidate constructor not viable: no known conversion from 'B' to 'boost::optional<boost::variant<A, B, C> >::rval_reference_type' (aka 'boost::variant<A, B, C> &&') for 1st argument optional ( rval_reference_type val ) : base( boost::forward<T>(val) ) ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:877:5: note: candidate constructor not viable: no known conversion from 'B' to 'const boost::optional<boost::variant<A, B, C> > &' for 1st argument optional ( optional const& rhs ) : base( static_cast<base const&>(rhs) ) {} ^ /opt/compiler-explorer/libs/boost_1_64_0/boost/optional/optional.hpp:882:2: note: candidate constructor not viable: no known conversion from 'B' to 'boost::optional<boost::variant<A, B, C> > &&' for 1st argument optional ( optional && rhs )

1 0

missing libboost_zlib-vc140-mt-x64-1_66.lib
by Sebastian Pfützner 12 Mar '18

12 Mar '18

Hello, I tried to build boost iostreams with zlib support with the following command on Windows: b2 -j 10 --build-dir=build\x64 --stagedir=stage\x64 --toolset=msvc -sZLIB_SOURCE=L:\vc14\zlib\zlib-1.2.8 runtime-link=shared link=static threading=multi address-model=64 debug release stage But if I try to link my program using iostreams with zlib filter it complains about the missing file libboost_zlib-vc140-mt-x64-1_66.lib, and I see it was not built. I also tried editing the project-config.jam as described in the docs: http://www.boost.org/doc/libs/1_66_0/doc/html/bbv2/reference.html#bbv2.refe… Same result. I also tried to use a pre-built zlib binary. Same result. What should I do? here is the output of b2: - 32-bit : yes (cached) - arm : no (cached) - mips1 : no (cached) - power : no (cached) - sparc : no (cached) - x86 : yes (cached) - symlinks supported : no (cached) - junctions supported : yes (cached) - hardlinks supported : yes (cached) - C++11 mutex : yes (cached) - Boost.Config Feature Check: cxx11_auto_declarations : yes (cached) - Boost.Config Feature Check: cxx11_constexpr : yes (cached) - Boost.Config Feature Check: cxx11_defaulted_functions : yes (cached) - Boost.Config Feature Check: cxx11_final : yes (cached) - Boost.Config Feature Check: cxx11_hdr_mutex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_regex : yes (cached) - Boost.Config Feature Check: cxx11_hdr_tuple : yes (cached) - Boost.Config Feature Check: cxx11_lambdas : yes (cached) - Boost.Config Feature Check: cxx11_noexcept : yes (cached) - Boost.Config Feature Check: cxx11_nullptr : yes (cached) - Boost.Config Feature Check: cxx11_rvalue_references : yes (cached) - Boost.Config Feature Check: cxx11_template_aliases : yes (cached) - Boost.Config Feature Check: cxx11_thread_local : yes (cached) - Boost.Config Feature Check: cxx11_variadic_templates : yes (cached) - has_icu builds : no (cached) warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - zlib : yes (cached) - bzip2 : no (cached) - lzma : no (cached) - iconv (libc) : no (cached) - iconv (separate) : no (cached) - icu : no (cached) - icu (lib64) : no (cached) - native-atomic-int32-supported : yes (cached) - message-compiler : yes (cached) - native-syslog-supported : no (cached) - pthread-supports-robust-mutexes : no (cached) - compiler-supports-visibility : no (cached) - compiler-supports-ssse3 : yes (cached) - compiler-supports-avx2 : yes (cached) - gcc visibility : no (cached) - long double support : yes (cached) warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. - libbacktrace builds : no (cached) - addr2line builds : no (cached) - WinDbg builds : yes (cached) - WinDbgCached builds : yes (cached) - zlib : yes (cached) - bzip2 : no (cached) - lzma : no (cached) Component configuration: - atomic : building - chrono : building - container : building - context : building - coroutine : building - date_time : building - exception : building - fiber : building - filesystem : building - graph : building - graph_parallel : building - iostreams : building - locale : building - log : building - math : building - mpi : building - program_options : building - python : building - random : building - regex : building - serialization : building - signals : building - stacktrace : building - system : building - test : building - thread : building - timer : building - type_erasure : building - wave : building

3 8

[Interval] Help debugging compiler optimization
by Tim van Erven 12 Mar '18

12 Mar '18

Dear all, I am trying to understand why I am getting different numerical results with the interval library depending on the optimization level of the compiler. I am attaching the smallest example I have been able to create: # On my Mac laptop Apple LLVM version 9.0.0 (clang-900.0.39.2) boost 1.66 (installed via homebrew) $ g++ foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) $ g++ -O2 foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (1.0000000000000000000000000000000000000000000000000000000000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (1.0000000000000000000000000000000000000000000000000000000000000000,1.0000000000000000000000000000000000000000000000000000000000000000) I would expect to get the same output in both cases, but the lower end-points are different in the second case, and seem wrong to me since third2 * 3.0 < 1.0. # On my Linux machine the effect is different: gcc version 5.4.0 20160609 boost 1.58 on Ubuntu 16.04.9 $ g++ foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) $ g++ -O2 foo.cpp -o foo $ ./foo third1 = 0.3333333333333333148296162562473909929394721984863281250000000000 third2 = 0.3333333333333333148296162562473909929394721984863281250000000000 v1 = (0.9999999999999998889776975374843459576368331909179687500000000000,1.0000000000000000000000000000000000000000000000000000000000000000) v2 = (1.0000000000000000000000000000000000000000000000000000000000000000,1.0000000000000000000000000000000000000000000000000000000000000000) Can anyone explain what is going on? Thanks in advance, Tim -- Tim van Erven<tim(a)timvanerven.nl> www.timvanerven.nl

7 14

[Boost.Serialization] (De-)serialization with class versioning
by Lars Ruoff 11 Mar '18

11 Mar '18

Hi, i use the class versioning feature of Boost.Serialization, with an external (non-intrusive) serialization function like this: BOOST_CLASS_VERSION(GAMEINFO, 1) template <typename Archive> void serialize(Archive &ar, GAMEINFO& gameSettings, const unsigned int version) { ar & gameSettings.NPODS; // ... if (version > 0) ar & gameSettings.ARENA_GOAL_EXCLUSION_RADIUS; } Now as soon, as i set BOOST_CLASS_VERSION(GAMEINFO, 1), i get version==1 in this serialize function, even when i *deserialize* (load from archive). I would have expected to get the version of the data in the saved archive in this case. Say i saved with an old version=0. Then my class evolved and i set BOOST_CLASS_VERSION(GAMEINFO, 1). But when reading the old archive, i expect version==0 in the function so i can react on it. Instead, i get always version==1, as soon as i compile with BOOST_CLASS_VERSION(GAMEINFO, 1), even when i'm reading old files! What am i missing? regards, Lars R.

3 7

boost::serialization - Non intrusive serialization of user-defined members?
by Lars Ruoff 05 Mar '18

05 Mar '18

Hi, I have a class structure like class MemberClass; class ContainerClass { MemberClass special_member; int other_members; }; Following the example in http://www.boost.org/doc/libs/1_66_0/libs/serialization/doc/ i want to write a non-intrusive serialization: template<class Archive> void serialize(Archive & ar, ContainerClass & c, const unsigned int version) { ar & c.other_members; // easy - built-in type serialize(ar, c.special_member, version); //use same version??? } Assuming there's is also a non-intrusive void serialize(Archive & ar, MemberClass & m, const unsigned int version); this compiles and works but i feel this is not the way to do it because it reuses the version number of the container class for the member class? So how to handle that? Must the Container class manage version of its members individually? I suggest to add a section "Non-intrusively Serializable Members" to documentation with an example. Cheers, Lars R.

3 7

[fiber] Fiber context switching during stack unwinding...
by Oliver Seiler 01 Mar '18

01 Mar '18

(Hopefully I'm not writing an essay for something that is a gcc/libstdc++/Linux bug) I've been using Boost.Context for a number of years now, to do something similar to what Boost.Fiber does. We recently upgraded our development target environment to Debian 9 (gcc 6.3), and moved up to Boost 1.62.0, so I've been looking at Boost.Fiber to replace how we're using Boost.Context (because it looks like it could greatly simplify our code, among other things). One thing I ran into with Boost.Context was that it interacted in some interesting ways with exception handling, and I haven't really seen any discussion about it. Specifically, switching contexts with an active exception (so during stack unwinding, or in a catch block) would result in weird behaviour in the other context (std::uncaught_exception() returning true, std::current_exception() returning the exception from the other context, try/catches in the new context causing new problems when switching back to the original context which is in the middle of stack unwinding, etc). I chalked that up to limitations of the context switching, though I haven't seen any mention of avoiding context switches with active exceptions; presumably this is some interaction with gcc's exception implementation, and would maybe need support from libunwind to save/restore the exception state (I don't recall if I checked if clang produced similar results, though I'll probably give it a go when I have the chance). So I wasn't surprised when I ran into similar problems with Boost.Fiber. I am wondering why this aspect of usage isn't discussed in any of the documentation; it would be nice if these libraries could work well with language features like exceptions, but I understand that the language spec doesn't really speak to the stack switching happening under-the-hood. It actually wouldn't surprise me that this wasn't even a problem in all environments, and just happens to be an artifact of the Linux implementation, but then we're either talking about unspecified or undefined behaviour, but would be nice to know. Even in the documents going through the C++ standards committee I don't see much mention of how things like coroutines should interact with something like std::current_exception() (perhaps because it is assumed to "just work" and doesn't need additional comment?) Anyone else ever run into issues related to this? Seems like any use of RAII for exception handling would easily run into problems. Mostly I've just found ways to work around it (e.g., not allowing the context switch if std::uncaught_exception() or std::current_exception() indicate it would be unsafe to do so, typically by throwing another exception) but this tends to make libraries harder to use correctly (e.g., can't really allow context switching in a destructor, or in a function called from a destructor, etc). Cheers Oliver

3 4

why boost does not have skip list implementation?
by David Frank 01 Mar '18

01 Mar '18

like java concurrentSkipListSet for example. Thanks, David

1 0