- Boost - lists.boost.org

[1.37.0][Test] Release branch Boost.Test failures?
by Beman Dawes 11 Oct '08

11 Oct '08

Boost.Test continues to fail ifstream_line_iterator_test on all platforms except Windows. http://beta.boost.org/development/tests/release/developer/test.html What's up? When will this be fixed or marked up as an expected failure? --Beman Running 2 test cases... ../libs/test/test/ifstream_line_iterator_test.cpp(35): error in "test_default_delimeter": check *it == "acv ffg" failed [acv ffg != acv ffg] ../libs/test/test/ifstream_line_iterator_test.cpp(38): error in "test_default_delimeter": check *it == "" failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(41): error in "test_default_delimeter": check *it == " " failed [ != ] ../libs/test/test/ifstream_line_iterator_test.cpp(63): error in "test_custom_delimeter": check *it == "\n{ d \n dsfg\n" failed [ { d dsfg != { d dsfg ] ../libs/test/test/ifstream_line_iterator_test.cpp(66): error in "test_custom_delimeter": check *it == "\n" failed [ != ] *** 5 failures detected in test suite "Master Test Suite"

2 2

Coroutines and Output Iterators
by Mathias Gaunard 11 Oct '08

11 Oct '08

When one wants to generate some range of data, the usual approach is to write the data to some output iterator passed as an argument. However, that approach has a few drawbacks: it is necessary to provide a range (often of a non-known size) to write the data on, and it will be possible to consider that data only once all elements have been copied to the output. An alternative approach is returning a smart range which will generate the elements as it is being iterated. It is somewhat what the Boost.Range update in the review queue does. This approach has many advantages, since storage may not be needed and transformations can be combined on top, avoiding unnecessary iterations. Writing smart iterators/ranges that generate data, though, is much more difficult than writing generators using the previous solution, especially in recursive scenarios where the iterators will need to maintain a stack themselves. Another solution is coroutines, which allows to return data then reenter later in the same context and keep going. The results of a coroutine can then be iterated as they come, giving the advantages of smart iterator/ranges while keeping the syntax of output iterators. It is however at the cost of some stack allocation at the beginning (which can be improved using pools) and context switches at each iteration. What I propose is thus to make an output iterator that will yield the data within a coroutine context. With that solution, one writes generators as functions writing to output iterators, but those iterators might as well be writing to containers than actually yielding the result, which means the person designing the generator does not have the overhead of coroutines forced upon him. The syntax would be generate(boost::bind(&boost::transform, range, _1, f)) which would return a range similar to that of boost::make_transform_range(range, f). (boost::transform being just std::transform for ranges) The coroutine GSoC library from 2006 does offer that kind of thing, but not as non-intrusive output iterators. (I don't even get why it needs to call self.__self_exit__() at the end). I thus propose a simple output iterator that yields on iteration be made. By the way, what is the status of that library? I haven't heard of it for quite a while.

4 5

[multi_array] Slices, views and sub_arrays
by Robert Jones 10 Oct '08

10 Oct '08

Hi All I'm still plugging away at trying to make use of multi_array, but I seem to be having a few problems! I suspect my understanding of the basic paradigm is flawed. I'm bit confused about views and slices. If I start with a rectangular, 2 dimensional grid, take a view of the whole grid, and then use a single subscript to index into that view, then I expected the result to be a view of one less dimension then the original view. However, it seems to be a "sub_array". #include "boost/multi_array.hpp" struct Cell { int i; }; int main( ) { typedef boost :: multi_array_types :: index_range range; boost :: multi_array< Cell, 2 > grid( boost :: extents[ 9 ][ 9 ] ); boost :: multi_array< Cell, 2 > :: const_array_view< 2 > :: type const_grid_view = grid[ boost :: indices[ range( ) ][ range( ) ] ]; boost :: multi_array< Cell, 2 > :: const_array_view< 1 > :: type const_row_view = const_grid_view[ 5 ]; return 0; } The error message from the last assignment is this sample.cpp: In function `int main()': sample.cpp:13: error: conversion from `boost::detail::multi_array::const_sub_array<Cell, 1u, const Cell*>' to non-scalar type `boost::detail::multi_array::const_multi_array_view<Cell, 1u, const Cell*>' requested which seems to confirm I've got all my consts and dimensions correct. So, why is this wrong? Also, does the return type of sub_array, rather than array_view, mean that the contents of the relevant cells have been copied? Thanks - Rob.

2 1

[website] libs/* --> doc/libs/BOOST_VERSION/libs/* rewriting rule
by joaquin＠tid.es 10 Oct '08

10 Oct '08

Hello, The website PHP is devised in such a way that documentation URLs are automatically rewritten to point to the specific Boost version most recently shipped. For instance, if I type the following in my browser: http://www.boost.org/libs/smart_ptr/smart_ptr.htm I get the following redirection: http://www.boost.org/doc/libs/1_36_0/libs/smart_ptr/smart_ptr.htm This is fine in that it allows us to keep a historic record of documentation across Boost versions. My little complain is that the automatic redirection makes it all too easy to inadvertently use version-specific URLs when referring to Boost docs in external contexts (blogs, forums, etc.) This is in my opinion unfortunate because such URLs are stuck in time and do not reflect the evolution of the library. Of course it's easy to get to the most recent info, but untrained eyes might miss the detail and take the version-specific URL for the most updated reference. A simple Google search (http://tinyurl.com/42ufrn ) reveals that these version-specific URLs are beginning to proliferate. Maybe is it a good idea to not apply this redirection and instead serve the most updated docs for non-version-labeled URLs? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 2

Getting the types of arguments for a bind.
by Michael Marcin 10 Oct '08

10 Oct '08

I want to take a boost::bind functor and get the type of its arguments. I can't find any sort of introspection api documented. I tried using mpl but what I came up with doesn't seem to work. Is there a way to do this? A distilled version of my failed attempt follows #include <boost/bind.hpp> #include <boost/mpl/find.hpp> #include <boost/type_traits/function_traits.hpp> template< typename Function, int N > struct arg_n; template< typename Function > struct arg_n< Function, 1 > { typedef typename boost::function_traits< Function >::arg1_type type; }; template< typename Callback, int ArgN > struct arg_type; template< typename Return, typename Signature, typename Args, int ArgN > struct arg_type< boost::_bi::bind_t<Return,Signature,Args>, ArgN > { typedef typename boost::mpl::find< Args, boost::arg<ArgN> >::type iter; // +1 for 0 based find vs 1 based arguments typedef typename arg_n<Signature,iter::pos::value + 1>::type type; }; void foo( int a ) {} template< typename Callback > void bar( Callback cb ) { // trivial usage typedef typename arg_type< Callback, 1 >::type ArgType; cb( ArgType() ); } int main() { bar( boost::bind(&foo,_1) ); } Thanks, -- Michael Marcin

2 1

[shared_ptr] Why operator< uses internal_less?
by dariomt＠gmail.com 10 Oct '08

10 Oct '08

I see that operator== and operator!= are implemented comparing the pointer inside the shared_ptr's using get(), but operator< uses _internal_less, that does a different thing. I thought that operator< would also be implemented using get(), so please, can you share the rationale behind the need for _internal_less? TIA

7 6

[1.37] Trivial but Boost wide patch?
by John Maddock 10 Oct '08

10 Oct '08

There's a problem in 1.37 as it stands in that: * If Boost.TR1 is in the include path, and, * A Boost header is included that includes <cmath>. Then the TR1 version of <cmath> gets included. This is relatively harmless on *nix platforms - except for somewhat longer compile times - but for windows compilers that support auto-linking then the headers want to link to the math TR1 libraries even if the user is actually using a header only library like spirit for example. This is the subject of bug report: http://svn.boost.org/trac/boost/ticket/2392. There is a trivial fix, which is to replace #includes of <cmath> with <boost/config/no_tr1/cmath.hpp>: I've just applied this to Trunk (so you know who to blame if this causes any issues!), but should this be applied to the release branch as well? Changeset here: http://svn.boost.org/trac/boost/changeset/49254/trunk Regards, John.

2 1

[graph] compilation broken when mpi enabled
by Juergen Hunold 10 Oct '08

10 Oct '08

Hi ! It seems that change 49178 http://svn.boost.org/trac/boost/changeset/49178 broke compilation of Boost.Graph when mpi is configured. That might be the reason the regression tests are still green. (Would be nice if the Graphiz Loader had some UnitTests, too ;-)) This commit changed libs/graph/build/Jamfile.v2 to contain: > + > +############################################################ > +# Distributed-memory parallel graph library (Parallel BGL) # > +############################################################ > +use-project /boost/mpi : ../../mpi/build ; > +import mpi ; > +if [ mpi.configured ] > +{ It seems that Doug committed some local changes by accident. Please add either the missing files or revert libs/graph/build/Jamfile.v2. 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 1

[1.37][mpl] Merge gcc 4.4 fix.
by Daniel James 10 Oct '08

10 Oct '08

Hi, It it okay to merge the mpl part of this change to release? http://svn.boost.org/trac/boost/changeset/48960/ It fixes a preprocessor error in gcc 4.4 which stops a lot of libraries from working with that compiler. The python part of the patch isn't required, the error is due to mpl's preprocessed headers not including the boost preprocessor headers and doesn't occur in other libraries that use iteration, as they always include the headers. I've had a look through the test results and everything seems to be working. Daniel

2 1

[accumulators] Dependent and sliding accumulatos_set
by vicente.botet 10 Oct '08

10 Oct '08

Hi, The acuumulator library allows to determine dependency between accumulator, but not between accumulator_sets. I would like to define an accumulator_set c so when we cumulate in two others c1 and c2 accumulator_set we cumulate also in c, some thing like typedef dependable_acumulator_set <double, ...> dependable_acc_type; dependable_acc_type c1, c2; dependable_acc_type c=c1+c2 dependable_acc_type c3; c+=c3; c1(1); c2(1); c3(2); assert(count(c)==3); assert(sum(c)==4); How dependable_acumulator_set can be defined? Here follows the interfaces of such a class and the pseudo code, I've named the class dependable_acumulator_set, sorry but I have not found a shorter and better name (may be observed/listened?) template <typename T, typename F, typename W> class dependable_acumulator_set : public acumulator_set<T,F,W> { public: dependable_acumulator_set(); void add_dependent(dependable_acumulator_set&); void remove_dependent(dependable_acumulator_set&); template<typename A1> void operator ()(A1 const &a1) { for (acc in dependents) { acc(a1); } this->acumulator_set_type::operator()(a1); } dependable_acumulator_set<T,F,W>& operator+=(dependable_acumulator_set<T,F,W>); dependable_acumulator_set<T,F,W>& operator-=(dependable_acumulator_set<T,F,W>); }; template <typename T, typename F, typename W> dependable_acumulator_set<T,F,W> operator+()(dependable_acumulator_set<T,F,W>,dependable_acumulator_set<T,F,W>); In addition I would like to be able to cummulate on a sliding window, e.g. on the last N cummulated values. I have see the tail accumulator, but I dont know how to define a min_tail accumulator with the current framework. I would like a class that behaves like: typedef sliding_acumulator_set <double, ...> sliding_acc_type; sliding_acc_type c(window=2); c(1); c(5); c(2); assert(count(c)==3); assert(sum(c)==7); assert(min(c)==2); We can state the sliding window at compile (template parameter) or run time (constructor parameter). template <std::size Window, typename T, typename F, typename W> class static_sliding_acumulator_set; template <typename T, typename F, typename W> class sliding_acumulator_set; Of course the complexities of the sliding accumulators operations is increased. Of course it will be interesting to have a sliding dependable accumulater set. It would be great to integrate these features on a unique class (accumulator_set?) in a clean way. template <typename T, typename F, typename W, typename DependablePolicy, typename SlicingPolicy> class acumulator_set; Please let me know if this can be done in a better way. Is there any interest on these features? Eric, what do you think? Best, Vicente

1 0