- Boost - lists.boost.org

[1.44] Snapshot available
by Beman Dawes 26 Jul '10

26 Jul '10

The daily release snapshots are working fully again. That's important because the releases are based on the snapshots. See http://boost.cowic.de/rc/ --Beman

1 0

Bugs in program_options library
by Jorge Lodos Vigil 26 Jul '10

26 Jul '10

Hi The function options_description::find_nothrow throws an exception when there are at least 2 exact matches. Since this function is in the public interface this could be considered a bug (it must not throw). Please note that this function is used several times within the implementation without try clauses. The exception thrown might be being used by callers of the method find, so you cannot just remove it. It is best to implement find and find_nothrow as follows: const option_description& options_description::find(const std::string& name, bool approx, bool long_ignore_case, bool short_ignore_case) const { shared_ptr<option_description> found; vector<string> approximate_matches; vector<string> full_matches; // We use linear search because matching specified option // name with the declared option name need to take care about // case sensitivity and trailing '*' and so we can't use simple map. for(unsigned i = 0; i < m_options.size(); ++i) { option_description::match_result r = m_options[i]->match(name, approx, long_ignore_case, short_ignore_case); if (r == option_description::no_match) continue; if (r == option_description::full_match) { full_matches.push_back(m_options[i]->key(name)); found = m_options[i]; } else { // FIXME: the use of 'key' here might not // be the best approach. approximate_matches.push_back(m_options[i]->key(name)); if (!found) found = m_options[i]; } } if (full_matches.size() > 1) boost::throw_exception( ambiguous_option(name, full_matches)); // If we have a full match, and an approximate match, // ignore approximate match instead of reporting error. // Say, if we have options "all" and "all-chroots", then // "--all" on the command line should select the first one, // without ambiguity. if (full_matches.empty() && approximate_matches.size() > 1) boost::throw_exception( ambiguous_option(name, approximate_matches)); if (!found) boost::throw_exception(unknown_option(name)); return *found; } const option_description* options_description::find_nothrow(const std::string& name, bool approx, bool long_ignore_case, bool short_ignore_case) const { try { const option_description& d = find(name, approx, long_ignore_case, short_ignore_case); return &d; } catch(const std::exception&) { return NULL; } } This modification uncovers a bug in function cmdline::finish_option (cmdline.cpp) where find_nothrow is being called assuming that no exception will be thrown. The first part of this function might be modified to: void cmdline::finish_option(option& opt, vector<string>& other_tokens, const vector<style_parser>& style_parsers) { if (opt.string_key.empty()) return; const option_description* xd; try { // First check that the option is valid, and get its description. xd = &m_desc->find(opt.string_key, is_style_active(allow_guessing), is_style_active(long_case_insensitive), is_style_active(short_case_insensitive)); } catch(const std::exception&) { if (m_allow_unregistered) { opt.unregistered = true; return; } throw; } const option_description& d = *xd; // Canonize the name opt.string_key = d.key(opt.string_key); ........ } Now it can throw the correct exception thrown by the find method. This is the only way callers could know the correct exception. It was apparently working before because find_nothrow was throwing exceptions not captured within cmdline::finish_option. You may chose to eliminate the xd variable altogether and initialize and use d within the try clause. What is important is to call find instead of find_nothrow. The following test would have detected these problems and the one solved in https://svn.boost.org/trac/boost/ticket/4159: // Multiple arguments test_case test_cases2[] = { {"--fname file --fname2 file2", s_success, "fname: file fname2: file2"}, {"--fnam file --fnam file2", s_ambiguous_option, ""}, {"--fnam file --fname2 file2", s_ambiguous_option, ""}, {"--fname2 file2 --fnam file", s_ambiguous_option, ""}, {0, 0, 0} }; test_cmdline("fname fname2", style, test_cases2); This test may be added at the end of the test_guessing function in cmdline_test.cpp. I have created the ticked 4469 (https://svn.boost.org/trac/boost/ticket/4469) with this information. Thank you. Best regards Jorge

1 0

[chrono] [thread] boost.chrono changes to boost::condition_variables
by Morgan Henry 26 Jul '10

26 Jul '10

Hello, I've been exploring the boost.chrono candidate library as a basis for some fixes to boost::condition_variables::timed_wait(). I have some questions: 1) What is the current state of the chrono library, and its likely path into boost? 2) Are the chrono API changes to boost::condition_variables likely to be accepted into the boost.thread library in their current form? (i.e introduction of wait_for(), wait_until(), and the introduction of a new explicit dependency from boost/thread/condition_variables on chrono::time_point etc...) 3) Are there any other planned changes to boost::condition_variables::timed_wait to allow use of POSIX clocks other than CLOCK_REALTIME? My ultimate goal is to provide an implementation of boost::condition_variables that allows access to the POSIX clock CLOCK_MONOTONIC for use through boost::condition_variables::timed_wait(). Specifically, providing an implementation that uses pthread_condattr_setclock(&attr, CLOCK_MONOTONIC) at boost::condition_variables initialisation, and use of pthread_cond_timedwait(..., &t) with clock_gettime(CLOCK_MONOTONIC, &t) in boost::condition_variables::timed_wait() and friends This change would provide reasonable behaviour of boost::condition_variables::time_wait() in presence of ongoing changes to the system clock. boost.chrono contributes to this goal by providing a clock abstraction and accessors to the appropriate POSIX clocks through class monotonic_clock, class system_clock, etc... Further to this, changes to boost::condition_variable::timed_wait() and similar would be required to use clock_gettime(CLOCK_MONOTONIC, &t) rather than boost::get_system_time() for calculations when the monotonic_clock is specified. I'm currently considering whether to trust that the boost.chrono API changes to the boost::condition_variables API are robust, and likely to persist for the future. Or to propose alternative changes localised to boost::condition_variables that achieve the goals above without the strong dependency on boost.chrono. Thanks for any comments or information about the above. Morgan http://www.bbc.co.uk/ This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this.

3 5

Re: [boost] Phoenix3 port to proto complete
by Thomas Heller 26 Jul '10

26 Jul '10

Doug Gregor wrote: > On Fri, Jul 23, 2010 at 11:14 AM, Thomas Heller > <thom.heller(a)googlemail.com> wrote: >> Mathias Gaunard wrote: >> >>> On 23/07/10 14:18, Thomas Heller wrote: >>>> Ladies and Gentlemen, >>>> I proudly announce that the port of phoenix3 is completed! All >>>> testcases pass! (some with minor modifications) >>>> >>>> So, What is next? Here is my proposed schedule: >>>> - fix some minor issues >>>> - improve boost.bind compatibility: make all boost.bind testcases pass >>>> - implement all boost.lambda testcases and make them pass, as far as it >>>> is >>>> reasonable >>>> - add support for C++0x lambdas >>>> - make interoperability testcases for std::function, boost::function >>>> - adapt the documentation >>>> - clean up code (some parts are a little messy as of now) >>>> - improve compile time >>>> >>>> Did I miss something? >>> >>> I would quite like to know how Phoenix 3 compares to Phoenix 2 in terms >>> of compile speed, even if you haven't fully optimized it yet. >> >> Let me give you a small example of what situation we currently have: >> >> For this test i used the core/primitives_test.cpp test and g++ 4.5 >> >> Phoenix3 total compile time: 3.421s >> Phoenix3 preprocess time: 1.755s >> Phoenix3 compile time of preprocessed code: 1.835s >> >> Phoenix2 total compile time: 1.891s >> Phoenix2 preprocess time: 0.745s >> Phoenix2 compile time of preprocessed code: 1.106s >> >> comparing with clang: >> >> Phoenix3 total compile time: 3.901s >> Phoenix3 preprocess time: 2.738s > > Ouch! The Clang guys will be looking into this > preprocessor-performance issue to see if we can do better. Thanks for > reporting this! > > - Doug Thanks for looking into this! FYI, I was able to identify one bottleneck for the preprocessor. It was by including boost/fusion/include/vector.hpp. I instead included the different boost/fusion/container/vector/vectorN.hpp and was able to reduce compile-time by one second. New timings for the above test are: thomas@sunshine ~/programming/boost $ compile-time g++ -I. libs/phoenix/test/core/primitives_tests.cpp complete compile time: real 0m2.385s user 0m2.253s sys 0m0.120s preprocessing time: real 0m1.254s user 0m1.230s sys 0m0.017s compile time without preprocessing: real 0m1.234s user 0m1.157s sys 0m0.067s thomas@sunshine ~/programming/boost $ compile-time clang++ -I. libs/phoenix/test/core/primitives_tests.cpp complete compile time: real 0m2.709s user 0m2.337s sys 0m0.340s preprocessing time: real 0m1.765s user 0m1.417s sys 0m0.337s compile time without preprocessing: real 0m1.011s user 0m0.913s sys 0m0.080s

1 0

boost-trunk compile failure gcc 4.4.3
by Gaetano Mendola 25 Jul '10

25 Jul '10

current trunk has a compilation failure, the following diff solves it Index: boost/optional/optional_io.hpp =================================================================== --- boost/optional/optional_io.hpp (revision 64315) +++ boost/optional/optional_io.hpp (working copy) @@ -74,12 +74,12 @@ else { if ( d != '-') - in.setstate( ios::failbit ); + in.setstate( std::ios::failbit ); d = in.get(); if ( d != '-') - in.setstate( ios::failbit ); + in.setstate( std::ios::failbit ); v = optional<T>() ; } Regards Gaetano mendola

2 1

Property tree bug
by OvermindDL1 25 Jul '10

25 Jul '10

I am attempting to use a recent boost trunk due to updates I need, however propertytree has a build bug that has already been submitted a few days ago, what is the status of this? The fix is already in the bug ticket. https://svn.boost.org/trac/boost/ticket/4459

2 2

Conflict with patent
by Francisco José Tapia 24 Jul '10

24 Jul '10

I am a teacher of programming in a Technical Professional Training School in Madrid ( Spain). I had wrote a counter balanced red-black tree in C++. The balanced trees have a counter in each node, which represent the number of nodes under it including itself. This counter permit to access to the nodes by their position in the tree. Due to this you can use a counter tree as a vector, access by position and insert and delete by position. Of course, the iterators of this trees have random access, an you can add or decrement the iterators any value . vector_tree<int>::iterator Alfa, Beta ; Alfa = Beta + 17 ; The algorithms are built from zero,without any book or article, because you need in each operation , not only modify the pointers, you must modify the counters too. The speed is good. In the worst case the delay respect to the equivalent STL functions is around 20%. I had checked in windows ( Visual Studio ) and Linux (GCC). My version have a 5 classes interface : vector_tree : This class is a counter balanced red-black tree and have the same interface than the STL class vector. The insertion , deletion and access to elements are log(N) operations. The other four classes are set , multiset , map and multimap. Internally they have a vector_tree. They have the same interface than the STL classes, plus the access by position and the random access iterators. My idea is to send you to examine , and if you think useful, make a new boost library. Today is finished to 95% . I hope have all finished by the first weeks of September. I am writing you because today, looking for other think I discovered a US patent “Positional access using a B-tree” ( US patent Number 7,120,637B2 Oct, 10, 2006), and I don't know if this patent prevent the publication of the code in your library, because you can consider the red-black trees an simplification of B-trees If prevent, and you don't have an idea about the utility of the code, I will stop the develop, and I will spend my time with new ideas The idea about the counter trees you can find in “The art of computer Programming “ Donald Knuth, and I have a previous version of this code wrote 10 years ago and presented in my exposition in the Oposiciones a Catedrático de Informática ( Madrid 2001) If you are interested in the code, mail me and I will send you. Francisco José Tapia E-Mail : fjtapia(a)gmail.com

11 15

[Serialization] Query
by Alapkumar Sinha 23 Jul '10

23 Jul '10

Hi, I am trying to use the serialization library in the following scenario. 1. I create one instance of an object in one process 2. Serialize it either with binary/text archive 3. Then send it through unix local socket to another process where the process deserializes Whatever examples available, it shows just archiving like below std::ofstream ofs("filename"); // use it to build and archive boost::archive::text_oarchive oa(ofs); // write class instance being pointed to // to the archive oa << g; /************/ But after this 1. I would like to copy the archived data to a buffer 2. Send the buffer throught a socket something like boost::asio::write(socket, boost::asio::buffer( buffer, sizeof(buffer)); Can someone help on how I can get this done. One more question: does the call boost::asio::write does serialization internally? If yes, still I would need how to get the buffer as mentioned in the query above a my transmission mechanism might change. Thanks, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

2 1

[Query] __sync_val_compare_and_swap_4
by Alapkumar Sinha 23 Jul '10

23 Jul '10

Hi , I am trying to use the Boost Interposes, specifically the message queue. When Im doing cross compiling boost libraries on Cronus mips board, I am getting below error undefined reference to `__sync_val_compare_and_swap_4' Upon analysis we found that in boost/interprocess/details/atomic.hpp, was throwing this error. I found the solution. I replaced this returned statement ( __sync_val_compare_and_swap_4 ) and included assembly language code in atomic.hpp. (volatile boost::uint32_t *mem, boost::uint32_t with, boost::uint32_t cmp) { /* return __sync_val_compare_and_swap(const_cast<boost::uint32_t *>(mem), cmp, with);*/ boost::uint32_t result; asm volatile(".set\tpush\n\t" ".set\tnoreorder\n\t" ".set\tnomacro\n\t" "1:\n\t" "ll\t%[result],0(%[mem])\n\t" "bne\t%[result],%[with],2f\n\t" "move\t%[result],$0\n\t" // delay slot "move\t%[result],%[mem]\n\t" "sc\t%[result],0(%[mem])\n\t" "beq\t%[result],$0,1b\n\t" "nop\n\t" // delay slot "2:\n\t" ".set\tpop" : [result] "=&r" (result) : [mem] "r" (mem), [cmp] "r" (cmp), [with] "r"(with) : "memory"); return result; } After this I was able to execute the message queue program successfully on the mips platform. Can someone confirm if this is the right solution? Regards, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

2 1

[interprocess] x86-64 bug?
by Bartosz Marcinkiewicz 23 Jul '10

23 Jul '10

Hello, I have modified a little an example doc_complex_map.cpp in order to use vector of integers which is a member (int_vector_) of structure stored as a shared map value (complex_data). Program works as expected on x86 (32bits). I get core dump on x86-64: (gdb) bt #0 0x000000000041ecfe in boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0ul>, boost::interprocess::iset_index> > >::priv_push_back (this=0x7f3435ae9260, x=@0x7fff77fe9eac) at /home/bma/opt/include/boost/interprocess/containers/container/vector.hpp:1239 #1 0x000000000041ed57 in boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0ul>, boost::interprocess::iset_index> > >::push_back (this=0x7f3435ae9260, x=@0x7fff77fe9eac) at /home/bma/opt/include/boost/interprocess/containers/container/vector.hpp:904 #2 0x0000000000401cf1 in operator() (this=0x7fff77fea0ee, x=@0x7f3435ae9218) at doc_complex_map.cpp:109 #3 0x0000000000401e8c in main () at doc_complex_map.cpp:146 Valgrind output is: [bma@dev2 example]$ vg ./doc_complex_map ==18738== Memcheck, a memory error detector. ==18738== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==18738== Using LibVEX rev 1804, a library for dynamic binary translation. ==18738== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==18738== Using valgrind-3.3.0, a dynamic binary instrumentation framework. ==18738== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==18738== For more details, rerun with: -v ==18738== ==18738== Invalid write of size 4 ==18738== at 0x41ECFE: boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0l>, boost::interprocess::iset_index> > >::priv_push_back(int const&) (vector.hpp:1239) ==18738== by 0x41ED56: boost::container::vector<int, boost::interprocess::allocator<int, boost::interprocess::segment_manager<char, boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family, boost::interprocess::offset_ptr<void>, 0l>, boost::interprocess::iset_index> > >::push_back(int const&) (vector.hpp:904) ==18738== by 0x401CF0: main::test_struct::operator()(complex_data&) (doc_complex_map.cpp:109) ==18738== by 0x401E8B: main (doc_complex_map.cpp:146) ==18738== Address 0x104c0f989 is not stack'd, malloc'd or (recently) free'd This is on boost 1.43. I am attaching source code. Thanks for any hints. -- Bartosz Marcinkiewicz e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl

1 1