- Boost - lists.boost.org

Serializing shared_ptr to const object
by Eric Bourlier 25 Oct '07

25 Oct '07

Hi, Is there a way to serialize a shared_ptr to a const object? For example: ar & shared_ptr<const A> b; I receive a compile error that prevents the above code from working.

2 1

which tag dispatch convention to use
by Stjepan Rajko 25 Oct '07

25 Oct '07

Hello, As I'm preparing the dataflow library for submission (a.k.a. signal network gsoc project), I'm revisiting some of the design choices. Since I'm not too experienced with generic library design, I was wondering if anyone would share some advice on which tag dispatch convention to use. For my specializable functions, I adapted what is used in fusion, e.g.: template<typename ProducerTag, ConsumerTag> struct operation_impl; template<> struct operation_impl<some_producer_tag, some_consumer_tag> { template<typename P, typename C> struct apply { typedef some_result_type type; static type call(P &p, C &c) { ... } }; }; and then free function `operation` extracts the tags from its arguments, calls operation_impl, and returns the result. Could someone tell me what the advantages/disadvantages of this approach are compared to, say, template<> struct operation_impl<some_producer_tag, some_consumer_tag> { // specify result type using result_type typedef or template<> struct result // ... template<typename P, typename C> some_result_type operator()(P &p, C &c) { ... }; }; , or the technique described in: http://www.boost.org/more/generic_programming.html, or any other tag dispatching convention I should be aware of? Thanks in advance! Stjepan

4 7

Who has commit rights? Use it!
by Jens Seidel 24 Oct '07

24 Oct '07

Hi, I recently posted a patch which fixes some g++ 4.3 compiler errors and warnings but it was mostly ignored. I was forced that's why to create bug reports (which you call ticket, don't know why) for each library (which is time consuming especially without email interface) (#1332 -- #1341). I assumed trivial bugs such as Index: boost/gil/extension/dynamic_image/apply_operation_base.hpp =================================================================== --- boost/gil/extension/dynamic_image/apply_operation_base.hpp (Revision 40416) +++ boost/gil/extension/dynamic_image/apply_operation_base.hpp (Arbeitskopie) @@ -100,7 +100,7 @@ // Create specializations of apply_operation_fn for each N 0..100 GIL_GENERATE_APPLY_FWD_OPS(99) -}; +} // unary application template <typename Types, typename Bits, typename Op> which lead to real compile errors (at least using -pedantic) will be fixed during minutes but I was wrong! Of course I know that not everyone can react as fast but why do not commit other people such elementary stuff? Instead many simple patches are rotting in the bug database. Is this useful? Is it enforced somewhere that only the maintainer is allowed to commit patches for his library? I understand of course that not trivial stuff which needs to be analysed cannot be handled this way but there are so many trivial patches just ignored ... Jens

3 2

[range][foreach] Range fixes broke foreach
by Beman Dawes 24 Oct '07

24 Oct '07

Looks like the range fixes broke foreach. See http://mysite.verizon.net/beman/bgd-win32-trunk-results.html --Beman

5 15

[interprocess] operator>> for offset_ptr
by Markus Schöpflin 24 Oct '07

24 Oct '07

Hello, offset_ptr.hpp:291 contains the following code for operator>>: template<class E, class T, class Y> inline std::basic_istream<E, T> & operator>> (std::basic_istream<E, T> & os, offset_ptr<Y> & p) { Y * tmp; return os >> tmp; p = tmp; } The last assignment is never executed as there is a return statement before it. This smells fishy. Regards, Markus

2 1

[interprocess] Problematic interface for intrusive_ptr
by Markus Schöpflin 24 Oct '07

24 Oct '07

Hello, as part of its interface intrusive_ptr requires the user to supply two functions: void intrusive_ptr_add_ref(T * p); void intrusive_ptr_release(T * p); These are called from within the implementation of the intrusive_ptr class. When compiling intrusive_ptr_test, cxx complains that intrusive_ptr uses undeclared functions, because the test includes the header file for intrusive_ptr before declaring those two functions. A quick and dirty fix for this would be to move the inclusion of intrusive_ptr.hpp after the declaration of those two functions, and indeed this fixes the compilation error on cxx, but in the long run maybe this implicit interface (relying on the user to somewhere provide two functions before the template is instantiated) should be turned into an explicit interface. Regards, Markus

6 13

[fusion] list/detail/at_impl.hpp, Suggest recrusive elem_at_c instead of recursive apply
by Larry Evans 24 Oct '07

24 Oct '07

In boost/fusion/.../list/detail/at_impl.hpp the apply is recursive; however, the only reason for the recursion is to "find the right element type". The other reason for apply is the same as that of the apply in.../vector/detail/at_impl.hpp. "find the right element type" in vector's at_impl is done with mpl::at. The similarity between list and vector at_impl would be more apparent if: template <typename Sequence, int N> struct elem_at_c { typedef typename mpl::eval_if< mpl::bool_<N == 0> , mpl::identity<typename Sequence::car_type> , elem_at_c<typename Sequence::cdr_type, N-1> >::type type; }; were used to find the right element type. Then the frist part of list::at_impl::apply would be: template <typename Sequence, typename N> struct apply { typedef elem_at_c<Sequence, N::value> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type; which is very similar to the counterpart in vector: template <typename Sequence, typename N> struct apply { typedef mpl::at<typename Sequence::types, N> element; typedef typename mpl::eval_if< is_const<Sequence> , detail::cref_result<element> , detail::ref_result<element> >::type type;

2 3

Relocating boost to a different namespace?
by Eric Niebler 24 Oct '07

24 Oct '07

I have heard unconfirmed rumors that someone has a script that takes Boost code and moves it into a different top-level namespace. Does such a script really exist? The goal is to be able to automatically munge Boost code so that several versions can be used in parallel without conflicts. If anybody is currently doing this, I'd love to hear from them. -- Eric Niebler Boost Consulting www.boost-consulting.com

6 25

random and TR1
by Eric Niebler 24 Oct '07

24 Oct '07

I infer from the wrappers in tr1/random.hpp that Boost.Random is not TR1-compliant. What are the differences, and what is the plan for bringing Boost.Random into conformance? Also, are the wrappers in tr1/random.hpp TR1-compliant, or are there still some differences? Thanks, -- Eric Niebler Boost Consulting www.boost-consulting.com

2 1

[thread] build path names change
by Juergen Hunold 24 Oct '07

24 Oct '07

Hi Anthony ! The latest change to Boost.Thread: URL: http://svn.boost.org/trac/boost/changeset/40348 introduced "feature.feature thrd-api" as "symmetric" feature, adding "thrd-api-pthread" to the build paths on linux. I'd like to have it asymmetric, so build paths will be as short as possible. The problem with the "symmetric" property is that you can't use "feature.set-default" to change the default value so the path element will disappear. Please find "thread.diff" with propose patch attached. Also thread.txt with output without patch and thread2.txt will patched Jamfile.v2. The other thing I noticed is the usage of "os.name" to distinguish between nt/unix/cygwin. I think this should use "target-os" in order to enable cross-compilation, but I don't know how to code this. Therefore cross-post to Boost.Build list in order to get some pointer on how to change if [ os.name ] = NT to if target-os = windows or something similar. 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 !

2 2