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

[unordered] order in container
by gast128 14 Jun '13

14 Jun '13

Hello all, although it's called 'unordered_set', it surprised me that an unordered container could have a different ordering although its contents are the same: void f() { boost::unordered_set<int> uset1; uset1.insert(10); uset1.insert(9); uset1.insert(8); boost::unordered_set<int> uset2; uset2.insert(8); uset2.insert(9); uset2.insert(10); //uset1: 8, 9, 10 //uset2: 10, 9, 8 bool b = uset1 == uset2; //ok, they are the same } Maybe it is somewhere in the documentation, otherwise maybe add a documentation note.

3 2

[accumulator] compiler error with quantil
by Philipp Kraus 14 Jun '13

14 Jun '13

Hello, I try to create a complex accumulator. I would like to use an accumulator for a box plot with the whisker data ( http://en.wikipedia.org/wiki/Box_plot ). My typedef shows at the momen like this: typedef boost::accumulators::accumulator_set<double, boost::accumulators::stats< boost::accumulators::tag::count, boost::accumulators::tag::sum, //boost::accumulators::tag::median, boost::accumulators::tag::mean, boost::accumulators::tag::variance, boost::accumulators::tag::min, boost::accumulators::tag::max, boost::accumulators::tag::extended_p_square > > Accumulator; I would like to create the 25% & 75% quantil and replace the median with the 50% quantil, so I have defined the ctor accumulator call like this: boost::array<double, 3> probs = {0.25, 0.5, 0.75}; m_times[p_name] = Accumulator( boost::accumulators::extended_p_square_probabilities = probs ); (the median is disabled and m_times is a std::map<std::string, Accumulator>). At this point I get a compiler errors: /Developer/opt/Boost/1.53.0/include/boost/accumulators/statistics/extended_p_square.hpp: In constructor 'boost::accumulators::impl::extended_p_square_impl<Sample>::extended_p_square_impl(const Args&) [with Args = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::accumulators::tag::accumulator, boost::accumulators::accumulator_set<double, boost::accumulators::stats<boost::accumulators::tag::count, boost::accumulators::tag::sum, boost::accumulators::tag::mean, boost::accumulators::tag::variance, boost::accumulators::tag::min, boost::accumulators::tag::max, boost::accumulators::tag::extended_p_square, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, void> >, boost::parameter::aux::empty_arg_list>, Sample = double]': /Developer/opt/Boost/1.53.0/include/boost/accumulators/framework/depends_on.hpp:319: instantiated from 'boost::accumulators::detail::accumulator_wrapper<Accumulator, Feature>::accumulator_wrapper(const Args&) [with Args = boost::parameter::aux::arg_list<boost::parameter::aux::tagged_argument<boost::accumulators::tag::accumulator, boost::accumulators::accumulator_set<double, boost::accumulators::stats<boost::accumulators::tag::count, boost::accumulators::tag::sum, boost::accumulators::tag::mean, boost::accumulators::tag::variance, boost::accumulators::tag::min, boost::accumulators::tag::max, boost::accumulators::tag::extended_p_square, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na, mpl_::na>, void> >, boost::parameter::aux::empty_arg_list>, Accumulator = boost::accumulators::impl::extended_p_square_impl<double>, Feature = boost::accumulators::tag::extended_p_square]' .... I need one accumulator for all the data. I'm using Boost 1.53. How can I create working code? Thanks for help Phil

2 3

Any debugging tips for Boost Interprocess shared memory crashes?
by Warren Postma 14 Jun '13

14 Jun '13

I am a newly humbled mediocre C++ programmer, who is completely unable to figure out why Boost interprocess shared memory classes frequently freeze or crash both at creation and deletion of the manager objects, both with the persistent and the windows-only non persistent versions of the classes. Do you ever debug things and it all just gets worse and worse the longer you try to fix it? http://stackoverflow.com/questions/17100597/does-boostinterprocesswindows-s… Today I am getting crashes in the boost shared memory manager object destructor, or deadlocks in WMI calls. It's in Boost 1.53, on Visual C++ 2008, and involves DLLs. I am unable to reproduce the insanity at a top level EXE demo, and I tried to build a exe-loads DLL1, which loads DLL2, which creates boost objects, which fail when you destroy them, but I am unable to extricate it from my project. So it could be one of the lovely compiler or linker or project settings in my Visual C++ project, something about Multithreaded Debug DLL and MFC and ATL and all the billion varieties of weird RTL and heap bugs that lurk in Visual C++ runtime libraries. I am not blaming boost, but I am at wits end here. I have about 80 hours into debugging this and it's only getting worse the more I look at it. After this I promise to go away, perhaps drink myself silly, and never ever again try to use C++ or boost. Or Windows. Because for all I know this could be a windows SxS issue with Visual Studio 2008 and its lovely assortment of DLLs and runtime SxS insanity. Warren

1 0

boost 1.49.0 on Redhat 5.2 link issues
by Stefan Schwarzer 13 Jun '13

13 Jun '13

Dear everybody, we need to backport boost 1.49.0 to Redhat 5.2. b2 ; b2 install --prefix=/usr/local succeeds and installs libraries and headers in /usr/local as requested (g++ 4.1.2-42, 32 bit PAE kernel). However, we have a problem even linking a mostly trivial example: #include <boost/filesystem.hpp> int main () { copy_file(boost::filesystem::path("atest"), boost::filesystem::path("btest")); } $ g++ testBoost.cpp -lboost_filesystem -lboost_system /tmp/cc10doAS.o: In function `boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)': testBoost.cpp: (.text._ZN5boost11filesystem39copy_fileERKNS0_4pathES3_[boost::filesystem3::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&)]+0x24): undefined reference to `boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_type, boost::system::error_code*)' collect2: ld returned 1 exit status The symbol is present in /usr/local/lib/libboost_filesystem and ldconfig does know about its location (see below). Also, trying to link statically or adding -pthread does not change the situation. We are desperate for advice... Roald and Stefan. $ nm -C /usr/local/lib/libboost_filesystem.so | grep 'boost::filesystem3::detail::copy_file' 00010ae0 T boost::filesystem3::detail::copy_file(boost::filesystem3::path const&, boost::filesystem3::path const&, boost::filesystem3::copy_option::enum_type, boost::system::error_code*) $ cat /etc/ld.so.conf include ld.so.conf.d/*.conf /usr/local/lib

2 2

boost::thread::attributes reference overload?
by Anthony Foiani 13 Jun '13

13 Jun '13

Greetings. I have a class that wraps a boost::thread object, and I would like to specify certain thread attributes at construction time. My first attempt looked basically like this: struct my_thread { static boost::thread::attributes getThreadAttr() { boost::thread::attributes attrs; attrs.set_stack_size( 256 * 1024 ); return attrs; } my_thread( Runnable func ) : thread_( getThreadAttr(), func ) {} boost::thread thread_; }; But that fails: g++ -std=c++0x -o thread-attr thread-attr.cpp \ -lboost_thread-mt -lboost_system -pthread ... /usr/include/boost/thread/detail/thread.hpp:191:9: note: \ template argument deduction/substitution failed: thread-attr.cpp:48:42: note: cannot convert ‘my_thread::getThreadAttr()()’ (type \ ‘boost::thread::attributes {aka boost::thread_attributes}’) to type ‘boost::thread::attributes& {aka boost::thread_attributes&}’ Replacing 'getThreadAttr' with a method that returns a non-const reference to internal static variables allows the program to compile and run successfully: static boost::thread::attributes & getThreadAttr() { static boost::thread::attributes attrs; static bool init = false; if ( ! init ) { attrs.set_stack_size( 256 * 1024 ); init = true; } return attrs; } The full program, with Linux compile lines, can be found at the bottom of this message and also at: http://foiani.home.dyndns.org/~tony/boost/thread-attr.cpp I did find a closely-related question on StackOverflow: http://stackoverflow.com/questions/13868619 Where Vicente replied (http://stackoverflow.com/a/13894968/784478) The needed overload template <class F, class Arg, class ...Args> thread(attributes const& attrs, F&& f, Arg&& arg, Args&&... args) is defined only if the compiler supports variadic templates and rvalue references. This could explain your problem. I guess the documentation could be improved to signal this clearly. Please could you create a Trac ticket to follow this issue? However, the compiler I'm using (g++ 4.7.2) has supported both of these features for years. According to this page: http://gcc.gnu.org/projects/cxx0x.html g++ has supported both of these features since 4.3. Josef_K (on freenode IRC #boost channel) was kind enough to try the sample code in their own environment, and they encountered the same errors on both g++ 4.8.1 and clang 3.4. The most likely explanation is that I'm doing something stupid. If anyone has the time to hit me with the clue-by-four, I would appreciate it. There is the possibility that Boost.Thread v4 fixes this (I'm on 1_51_0, which is Boost.Thread v3.0.1). I'd rather not try to transition libraries at this point, but if it has been fixed, confirmation would be welcome. For now, I'll most likely implement the "return reference to internal static" method in my project. It's a bit racy, but since I do all my thread creation through this one routine, I should be able to manage it. Anyway. I'm left feeling that there is a gap somewhere; whether it's in my understanding, in the older version of Boost.Threads, in compiler support / quirks, or elsewhere, I don't know. Regardless, thanks for the excellent library, and happy hacking! Best regards, Anthony Foiani Sample program follows: ======================================================================== // this should work: // g++ -std=c++0x -o thread-attr thread-attr.cpp -lboost_thread-mt -lboost_system -pthread // // this explodes: // g++ -std=c++0x -o thread-attr thread-attr.cpp -DRVALUE_REFERENCE_DOOM -lboost_thread-mt -lboost_system -pthread #include <iostream> #include <boost/function.hpp> #include <boost/thread.hpp> typedef boost::function< void ( void ) > Runnable; struct my_thread { #ifdef RVALUE_REFERENCE_DOOM // this doesn't work. static boost::thread::attributes getThreadAttr() { boost::thread::attributes attrs; attrs.set_stack_size( 256 * 1024 ); return attrs; } #else // this does work, but needs more structure before it can be // considered safe. static boost::thread::attributes & getThreadAttr() { static boost::thread::attributes attrs; static bool init = false; if ( ! init ) { attrs.set_stack_size( 256 * 1024 ); init = true; } return attrs; } #endif my_thread( Runnable func ) : thread_( getThreadAttr(), func ) {} void join() { thread_.join(); } boost::thread thread_; }; void foo() { std::cout << "foo!" << std::endl; } int main( int argc, char * argv [] ) { my_thread t( foo ); t.join(); return 0; }

2 1

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