- Boost - lists.boost.org

[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

[thread] Failed assertions under Borland?
by John Maddock 24 Oct '07

24 Oct '07

I'm seeing new regex regressions caused by assertions being fired in Boost.Thread: http://tinyurl.com/2okqzn Any ideas? Thanks, John Maddock.

2 5

[1.35.0] Progress report
by Beman Dawes 24 Oct '07

24 Oct '07

Most of the bigger infrastructure issues that were getting in the way have now been solved. The tarballs are working again, the missing files in the release/branch have been found, and both trunk and release branch regression reporting is cycling smoothly. There are still some outstanding testing issues, but they are at the level of individual test platforms rather than the whole testing system. Both developers and patch submitters have been active, so it isn't like we are starting from scratch, but the emphasis for release management is shifting to focus on reducing test failures in individual libraries. Looking at the regression test results, I'd like to call attention to these failures: conversion: lexical_cast_loopback_test on many platforms graph: csr_graph_test on many platforms python: import_ on many platforms range: iterator_range and sub_range on many platforms typeof: experimental_* on many platforms These are particularly worrisome from the release management standpoint because they affect many platforms and because I'm not seeing any attempts to fix or markup by their developers. For many of the other failures that affect a lot of key platforms, the developers are actively committing fixes on a regular basis so I assume these failures will be fixed or marked up in the near future. I'll be traveling Thursday through Tuesday, and will start moving libraries to the release branch when I get back. --Beman

9 11

Boost.Test issues
by Vladimir Prus 24 Oct '07

24 Oct '07

Looking at program_options failures, it seems like two platforms are fully not working due to issues in Boost.Test. First is MIPS: http://tinyurl.com/3c8avh Second is Sun: http://tinyurl.com/2yjlpd Can those issues be fixed in near future? Thanks, Volodya

3 5

BGL: traveling sales man
by Michael Held 24 Oct '07

24 Oct '07

hi boost, is there any traveling salesman implementation in BGL available or is anything in this direction planned? I could need such an implementation and would like to volunteer to help implementing/porting such an algorithm. with the help of this community - of course ;-) thank you & cheers, michael

6 7

[fusion] Getting rid of the incomplete type error for vector
by Markus Schöpflin 23 Oct '07

23 Oct '07

Hello, a number of platforms fail when fusion vectors are used with an error message like this: cxx: Error: ../boost/fusion/sequence/conversion/detail/as_vector.hpp, line 41: incomplete type is not allowed (incompletetyp) return vector<>(); -------------------^ Removing the inclusion of boost/.../detail/as_vector.hpp in the header file boost/.../vector/vector.hpp (line 12) solves the issue for me. Could the fusion author please indicate if this is the right fix, and if yes, could this fix please be committed ASAP? TIA, Markus

5 8