- Boost-users - lists.boost.org

Re: [Boost-users] [multi_index] emplace support
by Brian Wood 13 Jun '13

13 Jun '13

> The sad reality is I have very limited time to devote to evolving the > library, so this thing, although in principle simple to implement, has > been procrastinated for years now. Maybe if you sketch the first step that needs to be done here on the list someone will do that and then you can repeat for each step. Whoever would be willing to do this should ask the questions they have here, because there are a number of others on this list who can answer at least some of the questions. A tip to someone willing to do this: Boost Container has emplace support: http://www.boost.org/doc/libs/1_53_0/doc/html/container/move_emplace.html#c… so studying that implementation might be helpful. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

Output libs to specified folder
by Christopher Pisz 12 Jun '13

12 Jun '13

How can I tell boost to put the libraries in a directory that I specify? If I change stage-dir, it still appends /lib onto it. Is this possible? I want my libraries in C:\trunk\third_party\ Not in C:\trunk\third_party\lib Here is my build script: cd ..\boost SET PATH=$(PATH);..\bjam bjam.exe --stagedir=../../third_party --with-thread toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-date_time toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-system toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-regex toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-program_options toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage bjam.exe --stagedir=../../third_party --with-filesystem toolset=msvc-9.0 link=static threading=multi runtime-link=shared variant=debug stage

1 0

[chrono] Initializing system_clock from microseconds
by Kelly, Dan 12 Jun '13

12 Jun '13

I have been having some difficulty initializing a chrono::system_clock::time_point object. Specifically, I am trying to load a time stamp from a .pcap file using libpcap. I have a structure, pcap_pkthdr, which contains two fields: struct timeval { long tv_sec; /* seconds */ long tv_usec; /* and microseconds */ }; struct pcap_pkthdr { struct timeval ts; /* time stamp */ bpf_u_int32 caplen; /* length of portion present */ bpf_u_int32 len; /* length this packet (off wire) */ }; Where tv_sec and tv_usec are seconds and microseconds respectively relative to an epoch of Jan 1, 1970. I can use system_clock::from_time_t() to initialize the time_point to an 64-bit integer seconds (std:time_t). The question is, how do I add the microseconds to this value? My latest attempt is: void my_class::calculate_packet_statistics( const struct pcap_pkthdr *header ) { frame_interval_.intervalTimeStamp_ = system_clock::from_time_t( static_cast<time_t>( header->ts.tv_sec ) ); frame_interval_.intervalTimeStamp_ += microseconds( header->ts.tv_usec ); // This is the problematic line ... } However, this appears to simply add tv_usec to the internal representation of the time_point. The internal representation appears to be in 100ns ticks with an epoch other than Jan 1, 1970. This is on a windows x64 build but the same code will have to work on Linux as well. As a side note, I later do some date calculations using system_clock::to_time_t. I lose my fractional seconds here But since I am only working with dates, this is not a problem. Dan Kelly dan.kelly(a)sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

2 4

Question about the segfault in path::imbue that is being worked on at the moment
by Lars Hagström 12 Jun '13

12 Jun '13

Hi, I'm being bitten by the bug discussed here http://boost.2283326.n4.nabble.com/filesystem-segfault-in-path-imbue-after-… I'm encountering this when using boost 1.50. I have to support multiple boost versions, so I may bump into this in other versions as well. >From looking at the commit logs of boost svn I see that this is being worked on at the moment. But I would like to know what versions this bug affect, and if there are any ideas for a workaround. To me it looks like it affects most versions of boost filesystem, and I have been unable to come up with a workaround other than removing all use of filesystem in any place that could be called before main() has started. I would really like not having to do that! We use it quite a lot during static initialization... I've tried calling imbue(...) and codecvt() manually before using path, but that doesnt really help. The path_locale is in an anonymous namespace, which stops me from initializing it myself... Any other ideas? Sincerely Lars

1 0

[Interprocess] Interest in a NamedPipe component
by Geoff Shannon 11 Jun '13

11 Jun '13

Hey all, I'm in the early stages of planning an independent study for my CS program and what I'm hoping to do is write a Boost.Interprocess compatible implementation of NamedPipe. However, I don't want what I create to be too closely tied to what I personally want to use. So, if you have any possible interest in utilizing such a feature, please respond and we can chat a bit about what the desirable semantics might be. Specifically I'm interested in comments on what kind of persistence people would lke, and thoughts about whether the stream should be message oriented or not (or optionally so). (see http://www.boost.org/doc/libs/1_53_0/doc/html/interprocess/some_basic_expla… for more info about what I mean by persistence). Right now, my conception of what the key features of a NamedPipe implementation would be is a stream/message oriented communication channel between to unrelated processes. thanks! -- Geoff Nothing is ever easy.

1 0

quantil
by Philipp Kraus 11 Jun '13

11 Jun '13

Hello, I would like to create a box plot and use the static calls of the boost. Median / average etc works well, but I need also the 25% & 75% quantil of my data, I'm using a boost::accumulators::accumulator_set for calculating statistical data. Can I / How can I use this for the quantil calculation or should I do this myself? Thanks Phil

3 9

asio 1.43 ssl client certificate failure
by Stephan Menzel 11 Jun '13

11 Jun '13

Hello all, I am struggling with a bit of an esoteric question and have been debugging for days now. Basically, I am outfitting an existing app with asio based ssl HTTPS. Clients will have to use client authentication. Have my own root CA that signs both client and server certs. Extensive debugging using OpenSSL's s_client and s_server tools shows that the certificate trust chain etc is OK. Server side works fine with browsers, requests client certificate from browsers and only allows access if present. Alas, I can't get the client side to work. in boost 1.43 asio did not yet have any verification callbacks but it does have this: m_ssl_context.set_options( asio::ssl::context::tlsv1_client | asio::ssl::context::default_workarounds ); m_ssl_context.set_verify_mode( asio::ssl::context::verify_peer ); m_ssl_context.load_verify_file( myrootca ); m_ssl_context.use_certificate_file( myclient_cert, asio::ssl::context::pem ); m_ssl_context.use_private_key_file( myclient_key, asio::ssl::context::pem ); When I debug this using openssl s_server I see the connection failing with this message: ... SSL_accept:SSLv3 write certificate request A SSL_accept:SSLv3 flush data read from -0x7ff81be0 [-0x7ff8e2dd] (5 bytes => 5 (0x5)) 0000 - 16 03 01 00 07 ..... read from -0x7ff81be0 [-0x7ff8e2d8] (7 bytes => 7 (0x7)) 0000 - 0b 00 00 03 .... 0007 - <SPACES/NULS> write to -0x7ff81be0 [-0x7ff77a80] (7 bytes => 7 (0x7)) 0000 - 15 03 01 00 02 02 28 ......( SSL3 alert write:fatal:handshake failure SSL_accept:error in SSLv3 read client certificate B 2675716:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3274: ACCEPT A s_client or browser with the exact same keys can connect. Only asio fails and only on the client. Debugging shows that the client won't send the requested SSL certificates to the server. Also, when I register a verification callback in the impl like that: SSL_CTX *ctx = m_ssl_context.impl(); SSL *ssl = m_ssl_socket.impl()->ssl; SSL_CTX_set_client_cert_cb(ctx, &client_certificate_callback); and always return 1 in the callback, it still fails. Unfortunately I cannot upgrade to a post-war boost version and cannot touch OpenSSL either. It is on Windows here and uses OpenSSL 0.9.8i as far as I can see. Am I screwed? Or does anyone have an idea? Much appreciated? Stephan

2 2

[program_options] Can I use shorthand options with more than one char?
by Stefan Köhnen 10 Jun '13

10 Jun '13

Hello, I am currently migrating an old application with some weird command-line arguments. While using Boost program_options, I try to keep some of those arguments from the old version of the application, to assure the compatibility of some user scripts. My problem is that I couldn't find a way to add shorthand options with two or more characters. For example, if I add: ("testOption,to", "This is just a test-option") to the options_description, I only get -t as the shorthand for testOption. Is there some way to use longer shorthand options? Greetings, Stefan Köhnen

1 0

[thread] synchronized_value: value and move semantics
by Vicente J. Botet Escriba 08 Jun '13

08 Jun '13

Hi, boost::synchronized_value (not released yet [1][2][3]) is based on [4]. See below part of this paper adapted to the Boost.Thread interface. Currently boost::synchronized_value is in addition Copyable and Swappable. I was wondering if it is worth adding value and move semantics to synchronized_value. Making it EqualityComparable, LessThanComparable and Movable if the underlying type satisfy these requirements will allow to store them on a Boost.Container/C++11 container. Do you see something completely wrong with this addition? Has some of you had a need for this? Could you share the context? Best, Vicente [1] https://svn.boost.org/svn/boost/trunk/boost/thread/synchronized_value.hpp [2] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_valu… [3] https://svn.boost.org/svn/boost/trunk/libs/thread/example/synchronized_pers… [4] "Enforcing Correct Mutex Usage with Synchronized Values" by Anthony Williams http://www.drdobbs.com/cpp/enforcing-correct-mutex-usage-with-synch/2252002… ------------- [section The Problem with Mutexes] The key problem with protecting shared data with a mutex is that there is no easy way to associate the mutex with the data. It is thus relatively easy to accidentally write code that fails to lock the right mutex - or even locks the wrong mutex - and the compiler will not help you. std::mutex m1; int value1; std::mutex m2; int value2; int readValue1() { boost::lock_guard<boost::mutex> lk(m1); return value1; } int readValue2() { boost::lock_guard<boost::mutex> lk(m1); // oops: wrong mutex return value2; } Moreover, managing the mutex lock also clutters the source code, making it harder to see what is really going on. The use of synchronized_value solves both these problems - the mutex is intimately tied to the value, so you cannot access it without a lock, and yet access semantics are still straightforward. For simple accesses, synchronized_value behaves like a pointer-to-T; for example: boost::synchronized_value<std::string> value3; std::string readValue3() { return *value3; } void setValue3(std::string const& newVal) { *value3=newVal; } void appendToValue3(std::string const& extra) { value3->append(extra); } Both forms of pointer dereference return a proxy object rather than a real reference, to ensure that the lock on the mutex is held across the assignment or method call, but this is transparent to the user. [endsect] [/The Problem with Mutexes] [section Beyond Simple Accesses] The pointer-like semantics work very well for simple accesses such as assignment and calls to member functions. However, sometimes you need to perform an operation that requires multiple accesses under protection of the same lock, and that's what the synchronize() method provides. By calling synchronize() you obtain an strict_lock_ptr object that holds a lock on the mutex protecting the data, and which can be used to access the protected data. The lock is held until the strict_lock_ptr object is destroyed, so you can safely perform multi-part operations. The strict_lock_ptr object also acts as a pointer-to-T, just like synchronized_value does, but this time the lock is already held. For example, the following function adds a trailing slash to a path held in a synchronized_value. The use of the strict_lock_ptr object ensures that the string hasn't changed in between the query and the update. void addTrailingSlashIfMissing(boost::synchronized_value<std::string> & path) { boost::strict_lock_ptr<std::string> u=path.synchronize(); if(u->empty() || (*u->rbegin()!='/')) { *u+='/'; } } [endsect] [/Beyond Simple Accesses] [section Operations Across Multiple Objects] Though synchronized_value works very well for protecting a single object of type T, nothing that we've seen so far solves the problem of operations that require atomic access to multiple objects unless those objects can be combined within a single structure protected by a single mutex. One way to protect access to two synchronized_value objects is to construct a strict_lock_ptr for each object and use those to access the respective protected values; for instance: synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { strict_lock_ptr<std::queue<MessageType> > u1 = q1.synchronize(); strict_lock_ptr<std::queue<MessageType> > u2 = q2.synchronize(); if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } This works well in some scenarios, but not all - if the same two objects are updated together in different sections of code then you need to take care to ensure that the strict_lock_ptr objects are constructed in the same sequence in all cases, otherwise you have the potential for deadlock. This is just the same as when acquiring any two mutexes. In order to be able to use the dead-lock free lock algorithms we need to use instead unique_lock_ptr, which is Lockable. synchronized_value<std::queue<MessageType> > q1,q2; void transferMessage() { unique_lock_ptr<std::queue<MessageType> > u1 = q1.unique_synchronize(boost::defer_lock); unique_lock_ptr<std::queue<MessageType> > u2 = q2.unique_synchronize(boost::defer_lock); boost::lock(u1,u2); // dead-lock free algorithm if(!u1->empty()) { u2->push_back(u1->front()); u1->pop_front(); } } [endsect] [/Operations Across Multiple Objects]

2 4

[spirit] Compile error when using qi::locals<>
by Simon 07 Jun '13

07 Jun '13

Hi there, I'm pretty new to spirit and I need a semantic action to construct an object (that's fine) using a vector<double>, the vector is the problem. I'd really appreciate help with this error, or perhaps I'm not using the right technique, in which case, I'd need suggestions on how to proceed. Even if I don't use it anywhere, just adding the following to my grammar base class template parameter and adding the same to the rule declaration I need it for, it gives the monster error below. boost::spirit::qi::locals<std::vector<hs::Language::AX*> > I've also tried to make the vector a pointer, and allocate it on the first semantic action of a sequence. I've searched for an answer but found only one remote reference to boost needing to be recompiled to use c++11 features. So I did, but it didn't change anything (I use boost-1.49.0-r2). Also, I'm not sure if that is right, but my gcc command has this parameter: -std=c++0x I've put the full compile output at this address: http://next.n32.ca/locals.error.txt I will forget it there, so it should still be available in a few weeks/months... ;) And here are a few extracts of just the error lines: /usr/include/boost/spirit/home/qi/nonterminal/grammar.hpp:75:13: error: no matching function for call to 'assertion_failed(mpl_::failed************ (boost::spirit::qi::grammar<Iterator, T1, T2, T3, T4>::grammar(const boost::spirit::qi::rule<Iterator_, T1_, T2_, T3_, T4_>&, const string&) [with Iterator_ = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, T1_ = hs::Language::AX*(), T2_ = boost::spirit::unused_type, T3_ = boost::spirit::unused_type, T4_ = boost::spirit::unused_type, Iterator = __gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, T1 = hs::Language::AX*(), T2 = boost::spirit::locals<std::vector<hs::Language::AX*>*>, T3 = boost::spirit::unused_type, T4 = boost::spirit::unused_type, std::string = std::basic_string<char>]::incompatible_start_rule::************)(boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, hs::Language::AX*(), boost::spirit::unused_type, boost::spirit::unused_type, boost::spirit::unused_type>))' /usr/include/boost/proto/extends.hpp:537:29: error: use of deleted function 'boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, hs::Language::AX*(), boost::spirit::locals<std::vector<hs::Language::AX*>*>, boost::spirit::unused_type, boost::spirit::unused_type> > >, 0l>::expr()' /usr/include/boost/proto/detail/preprocessed/expr_variadic.hpp:37:12: error: 'boost::proto::exprns_::expr<boost::proto::tagns_::tag::terminal, boost::proto::argsns_::term<boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, hs::Language::AX*(), boost::spirit::locals<std::vector<hs::Language::AX*>*>, boost::spirit::unused_type, boost::spirit::unused_type> > >, 0l>::expr()' is implicitly deleted because the default definition would be ill-formed: /usr/include/boost/proto/detail/preprocessed/expr_variadic.hpp:37:12: error: no matching function for call to 'boost::spirit::qi::reference<const boost::spirit::qi::rule<__gnu_cxx::__normal_iterator<const char*, std::basic_string<char> >, hs::Language::AX*(), boost::spirit::locals<std::vector<hs::Language::AX*>*>, boost::spirit::unused_type, boost::spirit::unused_type> >::reference()'

3 5