- Boost - lists.boost.org

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 27 Sep '10

27 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

Re: [boost] [config] additions for gcc 4.0.1 and IBM V11.1.0.0 duetoMSM compile errors
by Christophe Henry 27 Sep '10

27 Sep '10

> The compiler file for this compiler is boost/config/compiler/vacpp.hpp. If > in doubt about stuff like this, then go to the config tests and look at the > config_info results for the compiler in question - it gives you this > information and much much more: > http://www.boost.org/development/tests/trunk/developer/output/IBM_Canada_Lt… Ah yes now I see it. Sorry. > The problem I have is that these compilers are passing the tests for these > macros. It wouldn't be the first time I see the gcc compiler supposedly supporting a feature but breaking if the construct using it is complicated enough. I spent days unsuccessfully trying to make the supposedly MPL-compatible gcc 3.4 compile MSM :( >I've just committed a stricter version of the test for > BOOST_NO_NESTED_FRIENDSHIP in case this is an Apple GCC specific problem, as > both the updated tests and the msm tests pass for me here with Linux > gcc-4.0.4. Thanks a lot! At least the problem seems to be quite limited. >I haven't tried gcc-4.0.1 on Linux as it means yet another gcc > build and install.... I'll leave that to you to try :-) Is it a variant of the famous "exercise left to the reader"? ;-) > Do you have a stricter test case than we currently use for > BOOST_NO_MEMBER_TEMPLATE_FRIENDS that more closely represents MSM's usage? Looking at your test case, the only possible cause I can imagine is that I'm taking an address of a foo static method in foobar so we could add this: template <class T> class foo { private: template<typename Y> friend class foobar; template<typename Y> friend class foo; template<typename Y> friend bool must_be_friend_proc(const foo<Y>& f); int i; static int my_func(){return 0;} // added public: foo(){ i = 0; } template <class U> foo(const foo<U>& f){ i = f.i; } }; template <class T> class foobar { int i; public: template <class U> foobar(const foo<U>& f) { i = f.i; } // added typedef int (*foofct) (); void test_address() { foofct fct=&foo<int>::my_func;} }; > Ah... just looked at the error messages and I'm not sure these are related > to that macro or not? It's hard to spot but I think this is pretty clear: "../boost/msm/back/dispatch_table.hpp", line 174.40: 1540-0300 (S) The "private" member "boost::msm::back::state_machine<<unnamed>::player_,boost::msm::back::NoHistory,boost::msm::back::favor_runtime_speed>::call_no_transition<<unnamed>::play>(library_sm &, int, int, const play &)" cannot be accessed. dispatch_table is made friend so this should not happen. >You could try emailing the IBM test-runners > directly - they're quite helpful at tracking down issues like this - just > don't tell anyone ;-) Of course not! It'll stay strictly between us :) I'll take the subject to Michael then. Thanks, Christophe

2 1

Re: [boost] [Boost-commit] svn:boost r65594 - in trunk: boost/config/platform boost/config/stdlib libs/config/doc libs/config/doc/html libs/config/doc/html/boost_config libs/config/test libs/config/test/all
by Jürgen Hunold 27 Sep '10

27 Sep '10

Hi John, this commit broke the boost tests. On Sunday, 26. September 2010 11:30:45 john(a)johnmaddock.co.uk wrote: >Added: > trunk/libs/config/test/boost_no_limits_lowest.ipp > Modified: trunk/libs/config/test/all/Jamfile.v2 > +test-suite "BOOST_NO_NUMERIC_LIMITS_LOWEST" : > +[ run ../no_limits_lowest_pass.cpp ] > +[ compile-fail ../no_limits_lowest_fail.cpp ] ; error: Unable to find file or target named error: '../no_limits_lowest_fail.cpp' error: referred from project at error: '/home/hunold/src/devel/boost/libs/config/test/all' It seems you forgot to add one file. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0