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

Program Options / Windows command line
by asif saeed 24 Aug '11

24 Aug '11

Hi, The page at http://www.boost.org/doc/libs/1_47_0/doc/html/program_options/howto.html#id… says that the "split_winmain function is a portable mechanism provided by the library." Does that mean that the same code (containing the split_winmain function, that is) will also run on Linux, for example? I guess it would return normal args on Linux. Could you elaborate please? In addition, could you please post a link to a cookbook-type recipe for parsing windows command-line (that parses linux/unix command line as well)? Are there any tutorials to get up to speed with program options - especially, the windows command-line parsing stuff? Best regards, Asif

1 0

[thread] boost::this_thread::get_id causing interrupt
by Yi Ding 24 Aug '11

24 Aug '11

Hi everyone, I've been dipping my toes into boost threads, and I'm running into a strange issue. What I'm trying to do is to run a comparison between thread_ids. I have an object that's "owned" by a thread, and when something calls one of its functions, I'd like to compare the thread_id to the owner's thread id. So I thought that boost::this_thread::get_id would do the trick to figure out what the current running thread's thread id is. For some reason, when I call it, an interrupt is signalled to my main thread. Is boost::this_thread::get_id not the right thing to use here? Thanks in advance, Yi

1 1

Boost.Conversion review
by Gordon Woodhull 23 Aug '11

23 Aug '11

Hi all, The review of Vicente Botet Escriba's Conversion library starts this Saturday August 20 and continues through August 29. This library provides a general system for type-to-type conversion. As such, it can be thought of either as a substitute for overloading static_cast, or as an alternative to lexical_cast when the intermediate conversion to text is not wanted. The code is in the sandbox: http://svn.boost.org/svn/boost/sandbox/conversion/ And the docs are here: http://svn.boost.org/svn/boost/sandbox/conversion/libs/conversion_ext/doc/h… I'll send out a formal announcement when the review begins, but I wanted to send out this reminder because participation in summer months tends to be somewhat low. Your review and/or discussion would be greatly appreciated. As always, please post to the main Boost list if possible, or the boost-users list, or you can send your review directly to the Review Managers. Thanks, Gordon Woodhull, Review Manager Espen Harlinn, Review Manager Assistant

3 2

Re: [Boost-users] [IOStream] issue
by Sean Farrow 23 Aug '11

23 Aug '11

Hi: I forgot to include the error in the last message. The error is: error C2039: 'category' : is not a member of 'std::basic_string<_Elem,_Traits,_Ax>' traits.hpp 242 1 Surface Reader visual studio 2010, windows 7.1 sdk. Cheers Sean.

1 0

[iostreams] issue
by Sean Farrow 23 Aug '11

23 Aug '11

Hi: I am writing some serialization code that uses IOStreams as a filter. The following is the class I am trying to serialize. class MIDISurface { public: // surface variables std::wstring strSurfaceName; }; The string header file is included. I then have a template function as follows: template <class SerializingType> void SaveData(SerializingType Data, boost::filesystem::path FileName, bool EncryptData) { //Check file existance. if (boost::filesystem::exists(FileName)) //Delete file boost::filesystem::remove(FileName); //Now create a WOfstream to serialize the data. std::wofstream OutputStream(FileName.generic_wstring()); //Create a filtering_stream to allow us to encrypt the data if necessary. boost::iostreams::wfiltering_stream<boost::iostreams::output> FilteringStream(FileName.generic_wstring()); if (EncryptData) //FilteringStream.push(test); //add the encryption filter defined in Encryption.hpp. FilteringStream.push(OutputStream); boost::archive::xml_woarchive Archive(FilteringStream); //create an archive and assign the filtering stream. Archive << BOOST_SERIALIZATION_NVP(Data); } I am including the following headers. //Standard c++ headers. #include <fstream> #include <stdlib.h> #include <string> #include <boost/iostreams/traits.hpp> //boost filesystem headers. #include <boost/config.hpp> #define BOOST_FILESYSTEM_VERSION 3 #include <boost/filesystem/operations.hpp> #include <boost/filesystem/path.hpp> //Boost xml serialization headers. #include <boost/archive/xml_wiarchive.hpp> #include <boost/archive/xml_woarchive.hpp> //Data type boost serialization headers. #include <boost/config.hpp> #include <boost/serialization/string.hpp> #include <boost/Serialization/Vector.hpp> #include <boost/Serialization/Map.hpp> #include <boost/Serialization/nvp.hpp> //boost io streams header. #include <boost/iostreams/detail/config/wide_streams.hpp> #include <boost/iostreams/concepts.hpp> #include <boost/iostreams/detail/ios.hpp> // BOOST_IOS. #include <boost/iostreams/filter/stdio.hpp> #include <boost/iostreams/operations.hpp> #include <boost/iostreams/filtering_stream.hpp> I am using boost 1.47, from the installer from boost pro computing. Can anyone point in the direction of the solution. Any help appreciated. Sean

1 0

[Serialization | Multi-Array] About the array.hpp header
by Júlio Hoffimann 23 Aug '11

23 Aug '11

Dear all, After read the "Optimizations" section of Boost.Serialization docs ( http://www.boost.org/doc/libs/1_47_0/libs/serialization/doc/special.html#op…) i get confused about the need to include/use array.hpp header with std::vector<>. I just need to include <boost/serialization/vector.hpp> and all is done, correct? Furthermore, i'm wondering if there is some header to include for serialize boost::multi_array<> class without doing myself the overload of the "array wrapper" and serialization member functions. Thanks in advance, Júlio.

1 0

Serialization: how to port binary archives containing NAN created with version 1.43 to version 1.47?
by Terry McLendive 23 Aug '11

23 Aug '11

Hi everyone, I am encountering a particularly gnarly version of the backward-compatibility problem with binary archives that others have discovered (here: http://groups.google.com/group/boost-list/browse_thread/thread/f4e3287f6925…, for example). Specifically, I have a number of binary archives created with version 1.43 of the library that are unreadable using version 1.47. I'd like to "port" them forward, so my initial plan was to compile a simple translator program against the 1.43 library that would read the binary archives and save them as (1.43) text archives. Then, a second program compiled against the 1.47 library would read the text archives and save them as (1.47) binary. Easy peasy. Except: the archives contain NAN values, which work fine when everything is binary but fail to deserialize for any version of the library when the archive is text (or xml, apparently), for reasons I don't quite understand. So my question is: how can I take my (1.43) binary archives containing NAN values and get them into a format readable by the current (1.47) version of the library? Is it possible? Thanks, Terry (An aside: it seems strange that I'm allowed to serialize a NAN to text, but it breaks when I try to deserialize it... why not prevent the creation of un-deserializable archives at the point of serialization?).

3 4

Valgrind Supression Settings
by Jeffrey Walton 23 Aug '11

23 Aug '11

Hi All, Does anyone have supression specs for Boost? We're getting overwhelmed with Boost squawks, and we are concerned Boost noise is drowning out problems with our gear. A small sample is below. For the full run, there are about 12,000 lines, mostly relating to Boost. Jeff ... ==8199== 24 bytes in 1 blocks are still reachable in loss record 147 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BDF63: boost::unit_test::runtime_config::show_build_info() (unit_test_parameters.ipp:395) ==8199== by 0x50B3E16: boost::unit_test::unit_test_log_t::test_start(unsigned long) (unit_test_log.ipp:140) ==8199== by 0x50A8623: boost::unit_test::ut_detail::callback0_impl_t<int, boost::unit_test::ut_detail::test_start_caller>::invoke() (framework.ipp:71) ==8199== by 0x509D51D: boost::execution_monitor::catch_signals(boost::unit_test::callback0<int> const&) (callback.hpp:118) ==8199== by 0x509D59A: boost::execution_monitor::execute(boost::unit_test::callback0<int> const&) (execution_monitor.ipp:1282) ==8199== by 0x50A5891: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:413) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 148 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BDFA3: boost::unit_test::runtime_config::catch_sys_errors() (unit_test_parameters.ipp:409) ==8199== by 0x50B7CF2: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:63) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 149 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BDFE3: boost::unit_test::runtime_config::auto_start_dbg() (unit_test_parameters.ipp:418) ==8199== by 0x50B7CFF: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:65) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 150 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BE023: boost::unit_test::runtime_config::use_alt_stack() (unit_test_parameters.ipp:427) ==8199== by 0x50B7D07: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:66) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 151 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50D221C: boost::runtime::environment::rt_env_detail::new_var_record(boost::unit_test::basic_cstring<char const>) (new_allocator.h:89) ==8199== by 0x50D2A52: boost::runtime::environment::rt_env_detail::variable_data& boost::runtime::environment::rt_env_detail::init_new_var<bool, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char> >(boost::unit_test::basic_cstring<char const>, boost::nfp::named_parameter<char, boost::nfp::nfp_detail::no_params_type_t, char>) (environment.hpp:54) ==8199== by 0x50BDE39: T.6666 (environment.hpp:113) ==8199== by 0x50BE063: boost::unit_test::runtime_config::detect_fp_exceptions() (unit_test_parameters.ipp:435) ==8199== by 0x50B7D0F: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (unit_test_monitor.ipp:67) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ==8199== 24 bytes in 1 blocks are still reachable in loss record 152 of 999 ==8199== at 0x4C27CC1: operator new(unsigned long) (vg_replace_malloc.c:261) ==8199== by 0x50B7D4A: boost::unit_test::unit_test_monitor_t::execute_and_translate(boost::unit_test::test_case const&) (shared_count.hpp:87) ==8199== by 0x50A8940: boost::unit_test::framework_impl::visit(boost::unit_test::test_case const&) (framework.ipp:150) ==8199== by 0x50D7762: boost::unit_test::traverse_test_tree(boost::unit_test::test_suite const&, boost::unit_test::test_tree_visitor&) (unit_test_suite.ipp:207) ==8199== by 0x50A5C27: boost::unit_test::framework::run(unsigned long, bool) (framework.ipp:436) ==8199== by 0x50B4D42: boost::unit_test::unit_test_main(bool (*)(), int, char**) (unit_test_main.ipp:185) ==8199== by 0x475CC1: main (unit_test.hpp:59) ==8199== ...

1 0

[Review] Review results for Lockfree
by Hartmut Kaiser 23 Aug '11

23 Aug '11

All, The review for the Lockfree library written by Tim Blechman started July 18th 2011 and ended on July 28th. I counted 8 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Tim Blechmann's Lockfree library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The design of the library is sound, the API is usable. Except for naming issues (discussed below) almost no comments have been made on how to change it. People reviewing the library would like to see a more modular approach to lockfree data structures in general, possibly by exposing building blocks or by utilizing policies. The general interest was to have a more diverse set of data structures available, such as a lock-free linked list or bounded and fixed-sized data structures. Atomics Library --------------- As the initial review announcement stated, Lockfree depends on an external Atomics library, which has to be separately reviewed in order to get into Boost as a first class library. There has been some discussions whether Lockfree could be accepted without Atomics being reviewed. Others suggested Lockfree may be reviewed and added to Boost SVN only after Atomics got reviewed (this was mentioned in the review announcement as well). After all those discussions and based on the wide interest Lockfree data structures have, I'd suggest to add the current Atomics library as an implementation detail to Lockfree. Special handling of compilers which already have implemented std::atomics has to be added to Lockfree, though. In this case Lockfree should use the atomics from the stdandard library. Naming ------ The consensus was that the naming of the reviewed data structures has to be changed. The names should be either fifo and lifo or queue and stack. AFAIK, Tim already addresses this point. Documentation ------------- The consensus of almost everybody referring to the documentation was that it needs more work. Here is a short (but non-exhaustive) list of things being mentioned: - It lacks rationale and information about the implementation - The class synopsis of the data structures should be accessible from the "Reference" page. - Make non-thread-safe parts more explicit (fifo::empty is described as non-thread-safe) - Document exception guarantees - More information needed on internals, the design, and rationale I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://boost-spirit.com

1 0

Custom services using boost::asio
by Allan Nielsen 22 Aug '11

22 Aug '11

Hi I would like to migrate an application from using Glib::Source (glibmm event loop) to use io_service instead. The application is using glib::sources for two job: - Drive lots of network IO connection - Process internal event which are generated in side the application it self. The Io part is easy to fit into asio, but I'm having problems seeing what the best way is to implement the core application event processing. Using glib::source I could register an interface where two function is called: bool prepare (int &timeout); bool dispatch (sigc::slot_base *slot); Prepare could set a time out identifying how much time should elapse before dispatch is ready to process an event. When the time is passed, the glib main loop will call the dispatch function, where I then can process the internal events. How can this be implemented in boost::asio io_service? I have look at the section 7.5 in http://en.highscore.de/cpp/boost/asio.htmlbut he is using a thread and a blocking call. Using a thread is not a solution in my case. I would rather like either polling, or some kind of scheduling... I any body has some hints, examples, advices it would be most appreciated. -- Allan W. Nielsen

2 1