- Boost-users - lists.boost.org

[boost.test] floating point comparison with user defined type
by Georgios Sermaidis 21 Mar '18

21 Mar '18

Apologies, I just found the relevant documentation: http://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/testing_… <http://www.boost.org/doc/libs/1_66_0/libs/test/doc/html/boost_test/testing_…>

1 0

[Asio] How to implement a server and client that replies to all clients but one
by Gonzalo Garramuño 21 Mar '18

21 Mar '18

Hi. I want to have a variation on the chat server/client model in that there's a language with instructions being sent. Both the server and the client need to parse this language. When the server changes something, it sends the change in the language to all clients. When the client changes something it sends the change to the server which in turn resends it to all clients but, here's the catch, not to the one that sent the change in the first place. I managed the removal of the client by doing: ParserList::const_iterator i = clients.begin(); ParserList::const_iterator e = clients.end(); for ( ; i != e; ++i ) { try { if ( !(*i)->socket_.is_open() ) continue; std::string p = boost::lexical_cast<std::string>( (*i)->socket_.remote_endpoint() ); if ( p == id ) continue; (*i)->deliver( cmd ); } catch( const std::exception& e ) { LOG_CONN( "Parser::write " << e.what() ); } catch( ... ) { LOG_CONN( "Parser::write unhandled exception" ); } } } I managed to create a working version of the above also by modifying the asio async example using multiple inheritance for the parser (which both the client and the tcp_session inherit). However I am unhappy with this. I ask here to see if someone can suggest a more simple approach to this. -- Gonzalo Garramuño

2 1

[asio] Boost-1.65.0 TlsSlot leak on win32
by Klebsch, Mario 20 Mar '18

20 Mar '18

Hi, I am using boost version 1.65.0 in a 32 bit DLL. I use VS2005 When using ApplicationVerifier, I got application verifier stops due to leaked TLS slots. The TLS slots are allocated in win_tss_ptr_create(). Each slot is wrapped into RAII class win_tss_ptr. The constructor allocates the TLS slot and the destructor de-allocates it. I put printf-Statements in both methods and I see, that the constructor is called twice, while the destructor is not called at all. If I put a breakpoint into the destructor, it never triggers. The printf() satemets show, that the following instances have been constructed: boost::asio::detail::win_tss_ptr<class boost::asio::detail::call_stack<class boost::asio::detail::win_iocp_io_service,struct boost::asio::detail::win_iocp_thread_info>::context>::win_tss_ptr boost::asio::detail::win_tss_ptr<class boost::asio::detail::call_stack<class boost::asio::detail::strand_service::strand_impl,unsigned char>::context>::win_tss_ptr When I put a breakpoint into the constructor, I see, that both instances seem to be global variables > xxx.dll!boost::asio::detail::win_tss_ptr_create() Line 40 C++ xxx.dll!boost::asio::detail::win_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>::win_tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>() Line 42 + 0x3a bytes C++ xxx.dll!boost::asio::detail::tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>::tss_ptr<boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::context>() + 0xf bytes C++ xxx.dll!`dynamic initializer for 'boost::asio::detail::call_stack<boost::asio::detail::win_iocp_io_service,boost::asio::detail::win_iocp_thread_info>::top_''() Line 165 + 0xd bytes C++ msvcr80d.dll!_initterm(void (void)* * pfbegin=0x101c43a0, void (void)* * pfend=0x101ce9c0) Line 855 C xxx.dll!_CRT_INIT(void * hDllHandle=0x10000000, unsigned long dwReason=0x00000001, void * lpreserved=0x00000000) Line 316 + 0xf bytes C xxx.dll!__DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0x00000001, void * lpreserved=0x00000000) Line 492 + 0x11 bytes C xxx.dll!_DllMainCRTStartup(void * hDllHandle=0x10000000, unsigned long dwReason=0x00000001, void * lpreserved=0x00000000) Line 462 + 0x11 bytes C Does anyone on this list has an idea, why the destructors aren't called? Thanks in advance, Mario Klebsch -- Mario Klebsch Actia I+ME GmbH Mario.klebsch(a)ime-actia.de<mailto:Mario.klebsch@ime-actia.de> Dresdenstrasse 17/18 Fon: +49 531 38 701 716 38124 Braunschweig Fax: +49 531 38 701 88 Germany

2 2

C++Now 2018 Program Published
by Jon Kalb 19 Mar '18

19 Mar '18

Boosters, The program has (mostly) been published for C++Now 2018: http://cppnow.org/announcements/2018/03/2018-program-announced/ It promises to be an exciting event. It isn’t too late to decide to join us in Aspen this may: http://cppnow.org/registration/ Jon

1 0

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