September 2010 - Boost - lists.boost.org

Fwd: [test] crash with the following test
by Felipe Magno de Almeida 28 Sep '10

28 Sep '10

Hello, Since I couldn't solve the problem in boost-users list I'm forwarding here. ---------- Forwarded message ---------- From: Felipe Magno de Almeida <felipe.m.almeida(a)gmail.com> Date: Wed, Sep 22, 2010 at 2:07 PM Subject: [test] crash with the following test To: boost-users(a)lists.boost.org With boost 1.44.0 (the same happens with 1.43) the following test causes a crash in framework.ipp:388 with a dereference of a NULL pointer. The test_unit* res returns NULL from s_frk_impl().m_test_units[id] where id is 1. id is equal to 1 because when unit_test::framework::run is ran, id is INV_TEST_UNIT_ID is passed to it. Then in framework.ipp:399 if id == INV_TEST_UNIT_ID id is assigned the value in master_test_suite().p_id which is 1. I've verified that when master_test_suite is constructed it assigns INV_TEST_UNIT_ID to p_id, so I'm lost why this is 1 here. Then, back in framework.ipp:386 s_frk_impl().m_test_units there's only one element in the map and the id is 65535 and not one. -- test.cpp -- #define BOOST_TEST_MODULE parse_empty_import_documents #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_CASE (parse_empty_import_documents) { } -- test.cpp -- Any help would be appreciated. -- Felipe Magno de Almeida

2 5

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 28 Sep '10

28 Sep '10

> > I think so far I have failed to make my use case sufficiently clear, so > > I'll simplify and try to follow the Process. Take the following simple > > algorithm sum_ints: > > > > template<class First, class Second> > > int sum_ints_impl( std::pair<First, Second> const & p ) > > { > > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > > } > > > > int sum_ints_impl( int i ) > > { > > return i; > > } > > template<class T> > > int sum_ints( T const & t ) > > { > > return sum_ints_impl( t ); > > } > > Hi, how about the below. Concept IntOrPair is empty because you do not require it to have any operations. Keyword "explicit" indicates that we do not want it to be an auto-concept: concept map is > always required. The second concept_map implements the recursion. > > Regards, > &rzej > > explicit concept< typename T > IntOrPair > { > } > > concept_map IntOrPair<int> > { > } > > template< IntOrPair type1, IntOrPair type2 > > concept_map IntOrPair< std::pair<type1, type2> > > { > } > > template<IntOrPair First, IntOrPair Second> > int sum_ints_impl( std::pair<First, Second> const & p ) > { > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > } > > int sum_ints_impl( int i ) > { > return i; > } > > template<IntOrPair T> > int sum_ints( T const & t ) > { > return sum_ints_impl( t ); > } Well, I believe I got it wrong. It is concept maps where the specializtion is to tke plce. It should read: explicit concept< typename T > IntOrPair { int sum_ints_impl( T const& ); } concept_map IntOrPair<int> { int sum_ints_impl( int const& i ) { return i; } } template< IntOrPair type1, IntOrPair type2 > concept_map IntOrPair< std::pair<type1, type2> > { int sum_ints_impl( std::pair<First, Second> const& p ) { return sum_ints_impl(p.first) + sum_ints_impl(p.second); } } template<IntOrPair T> int sum_ints( T const & t ) { return IntOrPair::sum_ints_impl( t ); } Regrds, &rzej

2 1

New library ( countertree: Binary trees with access by position like the vectors)
by Francisco José Tapia 28 Sep '10

28 Sep '10

Is there any interest in a library implementing counter trees, which permit us to access to the elements by the position, as in the same way than a vector.The insertion, deletion and access to elements are operations O(log N). The iterator and const_iterator are random access iterators in the same way than the STL vector::iterator and STL vector::const_iterator. These iterators and const_iterators have a function pos() which provide the position in the tree. The first class implemented is vector_tree wich has the full interface of the STL vector and STL deque. When the information stored in the vector_tree is sorted, we can build the new classes boost::set, boost::multiset, boost::map and boost::multimap. These clases have the full interface of the STL set , multiset, map and multimap, plus a function which permit to access to the elements of the set, map... by the position. The iterators of this data stuctures are random access, and have a function to take the position of the element pointed by the iterator. The performance of these data stuctures is similar to the STL set, multiset, map and multimap You can find the documentation, the code and the test programs in : http://www.boostpro.com/vault/index.php?action=downloadfile&filename=counte… The compilers used for to check are GCC 4.5 ( 32 and 64 bits) and Visual Studio 2008 Thanks Francisco Tapia fjtapia(a)gmail.com

6 6

Re: [boost] [guidelines] why template errors suck
by Andrzej Krzemienski 28 Sep '10

28 Sep '10

> I think so far I have failed to make my use case sufficiently clear, so > I'll simplify and try to follow the Process. Take the following simple > algorithm sum_ints: > > template<class First, class Second> > int sum_ints_impl( std::pair<First, Second> const & p ) > { > return sum_ints_impl(p.first) + sum_ints_impl(p.second); > } > > int sum_ints_impl( int i ) > { > return i; > } > template<class T> > int sum_ints( T const & t ) > { > return sum_ints_impl( t ); > } Hi, how about the below. Concept IntOrPair is empty because you do not require it to have any operations. Keyword "explicit" indicates that we do not want it to be an auto-concept: concept map is always required. The second concept_map implements the recursion. Regards, &rzej explicit concept< typename T > IntOrPair { } concept_map IntOrPair<int> { } template< IntOrPair type1, IntOrPair type2 > concept_map IntOrPair< std::pair<type1, type2> > { } template<IntOrPair First, IntOrPair Second> int sum_ints_impl( std::pair<First, Second> const & p ) { return sum_ints_impl(p.first) + sum_ints_impl(p.second); } int sum_ints_impl( int i ) { return i; } template<IntOrPair T> int sum_ints( T const & t ) { return sum_ints_impl( t ); }

1 0

Interest in specialized types
by Henning Basold 28 Sep '10

28 Sep '10

Hello, in http://permalink.gmane.org/gmane.comp.lib.boost.devel/207794 Robert Ramey talked about wrapping some POD to increase type safety. Some time ago I used something similar to ensure that misuse of values can be found by the compiler. So I think that is something that can be generalized. The concept is to wrap a type into a class and restrict the interface. This ensures that values from one context (e.g. an id) can't be used in another context (e.g. adding of number or as an id for other objects). Attached is a very simple implementation where the needed concepts can be specified as parameter. To distinguish for example between different id types also a tag type can be specified. Do you think this might be a useful utility? Or is there something similar already available? I've searched the vault but did not find anything. Regards Henning

5 11

Recall: Boost Digest, Vol 3047, Issue 1
by Tan, Tom (Shanghai) 28 Sep '10

28 Sep '10

Tan, Tom (Shanghai) would like to recall the message, "Boost Digest, Vol 3047, Issue 1".

1 0

[asio] Question regarding io_service.post() and pool of threads
by Romain CHANU 28 Sep '10

28 Sep '10

Hi, I was looking at this website where the guy gives an interesting example about the use of a pool of threads and io_service.post(): http://mostlycoding.blogspot.com/2009/05/asio-library-has-been-immensely-he… However, something confuses me a bit, cf. the website "In just a bunch of lines of code we have a thread pool executing any arbitrary task whenever one thread is available. No need to address the usual multi-threading issues with concurrent jobs sharing few resources: just post what you need and let io_service take care of it!" Extracted from Boost Asio reference: "The io_service<http://www.boost.org/doc/libs/1_44_0/doc/html/boost_asio/reference/io_servi…> guarantees that the handler will only be called in a thread in which the run(), run_one (), poll() or poll_one() member functions is currently being invoked." For my understanding, since there is a pool of threads, a handler can run concurrently in different threads, even though we are using io_service.post(). Is that correct? My concern here is about the need or not to lock the data accessed by the handler. Thank you. Regards, Romain

3 3

Missing file
by Belcourt, Kenneth 28 Sep '10

28 Sep '10

Tests failed for this missing file. error: Unable to find file or target named error: '../no_limits_lowest_pass.cpp' error: referred from project at error: '/scratch/boost/boost/libs/config/test/all'

2 1

Re: [boost] [B-tree] Continuing development
by Brian Wood 28 Sep '10

28 Sep '10

OvermindDL1: <woodbrian77(a)gmail.com> wrote: >> >> Just fyi, I've been experimenting with a similar string -- >> http://webEbenezer.net/misc/lil_string.hh . >> >> If an operation would result in a string with length more than 255, >> an exception is thrown. ?This allows the length of the string to be >> marshalled with one byte. ?As you mention this limitation is not a >> problem in many circumstances. ?I'd quibble a little with it not being >> suitable for demanding applications. ?I think it is fine to use it in that >> context, but that you might need to also use other string classes. > > Why not use a compressed uint type? Google's Protocol Buffers > compressed uint compresses an uint just fine, below 128 will be >represented in one byte, etc..., it works very simply, by just having > the MSB be a marker indicating the last byte of the integer if it is > zero, thus it is base 128 instead of base 256 per byte, so as an > example: > hex -> compressed bits > 0 -> 0000 0000 > 1 -> 0000 0001 > 300 -> 1010 1100 0000 0010 > And so forth, and if you have looked in the protocol buffer source it > decodes each byte very quickly and efficiently. So if you are worried > about space, you could use this (especially since I have many use > cases where strings would exceed 255 characters, and we need a > 'bytestream' type or so too). I've thought about doing that and I'm using that technique in one place in my library. The only thing I can say is I like the documentation effect that the name lil_string has. I don't claim what you suggest is a bad idea, but at the moment I'm happy with what I have. -- Brian Wood Ebenezer Enterprises http://webEbenezer.net (651) 251-9384

1 0

[Atomic] Confusion about Atomicaty of atomic::exchange.
by cexer 27 Sep '10

27 Sep '10

Hey guys, I am very interested in Boost.Atomic library, but when I went deeply into the source code, I found there are mysteries that I can not fullly understand, for example, the implementation of atomic::exchange, list its implementation code (see. /atomic/builderhpp, line 47.) as follow : integral_type exchange(integral_type replacement, memory_order order=memory_order_seq_cst) volatile { integral_type o=load(memory_order_relaxed); // A do {} while(!compare_exchange_weak(o, replacement, order, memory_order_relaxed)); // B return o; } From my view, although atomic::load and atomic::compare_exchnage_weak are both atomic operations, the atomicity of atomic::exchnage is not guaranteed，take this illustrative code-snippet for example : atomic<int> i( 1 ); thread1 i.exchange( 100 ); thread2 i.exchange( 200 ); // C To help explanation, in the atomic::exchange method and the above code-snippet, I lable corresponding code fragments as A, B, C. Assume that thread1 is completed running A, but has not arrive B yet, at this moment values of i and o ( o is the temporary variable in atomic::exchange method, see source code of atomic::exchnage above. ) are: o == 1 i == 1 Since the atomic::exchange is not locked, and calling to atomic::load using memory order of memory_order_relaxed, under this circumstance, atomic::exchnage is not prevent from calling from more than one threads, so these is possibility that thread2 could call atomic::exchange (like the code C above) between A and B, after thread2 completed C, the value of i is changed, values of i and o values are now: o == 1 i == 200 Then thread1 arrives code B, because at this moment o! = i, calling to compare_exchnage_weak will fail, atomic::exchange them will went into infinite loop, this is terrible. I know I must missing something here, so I posting here, expecting that someone could please remind me a little bit?

2 1