Why boost::function_output_iterator has no accessor to the wrapped function/functor? In STL, algorithms using an output iterator or a function/functor usually return the iterator or function/functor received in parameter (e.g. std::copy, std::for_each) because they are passed by copy. Then if I use a boost::function_output_iterator, I can get a copy of that iterator in return, but then there is no way to extract the function/functor. Example: I have a set of points stored in a structure for range query (e.g. a kd-tree). There is a member function to get all points falling inside a given area and it produces its output in an output iterator. Now, suppose I only want to do some computation on those points for which I would actually don't need to store them all, e.g. an average of some kind. I could do the computation on the fly using a boost::function_output_iterator with a functor that accumulates the sum and the number of points and at the end, I would do the division. Alas, I can't unless the functor only keeps reference. I can't do it the classical way I could with std::for_each because I can't access the functor with boost::function_output_iterator. So, long story just to try to show that it would be useful, or is there some other considerations I didn't see that makes it a bad idea? -- Francois Duranleau

On Fri, 5 Oct 2007, Michael Fawcett wrote: [...]

Shouldn't you be able to accomplish what you want following the example at http://www.boost.org/libs/iterator/doc/function_output_iterator.html ? You would have

struct averager { averager(float3& p, int &t) : m_avg(&p), m_num(&t) {}

void operator()(const float3& rhs) const { *m_avg += rhs; *m_num++; }

float3* m_str; int *m_num; };

float3 avg(0, 0, 0); int total = 0; kdtree.within(bounds, boost::make_function_output_iterator(averager(avg, total))); avg /= total;

Yes, of course. I was mostly pointing out a difference from what we are used to in STL. I see no reason why it should be different, and it would actually be trivial to add the accessor. -- Francois Duranleau

Hi! This is a follow up to: http://article.gmane.org/gmane.comp.lib.boost.devel/165366 I have been using it since then, but I recently hit a problem when more than one namespace are associated to a type. Example: #include <boost/utility/swap.hpp> #define BOOST_INCLUDE_MAIN #include <boost/test/test_tools.hpp> #include <boost/array.hpp> int test_main( int , char*[] ) { // boost::array or anything in boost such that pair_type has std and // boost as associated namespaces typedef ::std::pair< ::boost::array< int , 1 > , int > pair_type ; pair_type p1 ; pair_type p2 ; p1.first[ 0 ] = p1.second = 0 ; p2.first[ 0 ] = p2.second = 1 ; ::boost::swap( p1 , p2 ) ; // whatever here, it doesn't matter BOOST_CHECK_EQUAL( p2.first[ 0 ] , 0 ) ; BOOST_CHECK_EQUAL( p2.second , 0 ) ; BOOST_CHECK_EQUAL( p1.first[ 0 ] , 1 ) ; BOOST_CHECK_EQUAL( p1.second , 1 ) ; return 0 ; } //----------------------------------------------------------------- Compiling this results in an ambiguity in the call of overloaded swap (at least, with gcc-4.0.2 and gcc-4.2.0): ../../../../boost/utility/swap.hpp: In function 'void boost_swap_impl::swap_impl(T&, T&) [with T = std::pair<boost::array<int, 1ul>, int>]': ../../../../boost/utility/swap.hpp:31: instantiated from 'void boost::swap_adl_barrier::swap(T&, T&) [with T = test_main(int, char**)::pair_type]' std_and_boost.cpp:17: instantiated from here ../../../../boost/utility/swap.hpp:20: error: call of overloaded 'swap(std::pair<boost::array<int, 1ul>, int>&, std::pair<boost::array<int, 1ul>, int>&)' is ambiguous /usr/lib/gcc/x86_64-redhat-linux/4.0.2/../../../../include/c++/4.0.2/bits/stl_algobase.h:92: note: candidates are: void std::swap(_Tp&, _Tp&) [with _Tp = std::pair<boost::array<int, 1ul>, int>] ../../../../boost/utility/swap.hpp:29: note: void boost::swap_adl_barrier::swap(T&, T&) [with T = test_main(int, char**)::pair_type] I tried to move boost::swap_adl_barrier::swap to boost_swap_adl_barrier::swap, but I still got the same error. I find it strange because I thought that 'using' directives were ignored for ADL. I also tried to write in namespace boost "using namespace boost_swap_adl_barrier;", but then the compiler complains that boost::swap is not found. So, is it a compiler bug, an ADL limitation, or is there a solution? For reference, here is the content of boost/utility/swap.hpp (stripped down a little): // Copyright (C) 2007 Steven Watanabe, Joseph Gauterin #include <algorithm> //for std::swap namespace boost_swap_impl { template<class T> void swap_impl(T& left, T& right) { using std::swap;//use std::swap if argument dependent lookup fails swap(left,right); } } namespace boost { namespace swap_adl_barrier { template<class T> void swap(T& left, T& right) { ::boost_swap_impl::swap_impl(left, right); } } using swap_adl_barrier::swap; } -- Francois Duranleau

Joel de Guzman wrote:

John Maddock wrote:

...

John Maddock wrote:

...

Just to point out that fusion is not currently being tested in the trunk, and the docs aren't linked to from the documentation index either.

Fusion's tuples are also causing some failures in Boost.TR1: http://beta.boost.org/development/tests/trunk/developer/output/COMSOFT-boost...

And while we're at it there are some regressions in the TR1 Sunpro results also caused by fusions tuples: http://beta.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo...

Given the tight release schedule I'd really like to get these solved if possible so I can update TR1 for 1.35.

I'll look into this today. I'm not quite sure about Sunpro though. I do not have the compiler.

Fixed. All tests pass on the compilers use. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Joel de Guzman wrote:

...

I'll look into this today. I'm not quite sure about Sunpro though. I do not have the compiler.

Fixed. All tests pass on the compilers use.

Unfortunately I'm still seeing a few issues with the latest tuples code on for instance HP Tru64: http://beta.boost.org/development/tests/trunk/developer/output/COMSOFT-boost..., probably an old EDG frontend problem? Thanks, John.

John Maddock wrote:

John Maddock wrote:

...

Just to point out that fusion is not currently being tested in the trunk, and the docs aren't linked to from the documentation index either.

Fusion's tuples are also causing some failures in Boost.TR1: http://beta.boost.org/development/tests/trunk/developer/output/COMSOFT-boost...

And while we're at it there are some regressions in the TR1 Sunpro results also caused by fusions tuples: http://beta.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo...

Given the tight release schedule I'd really like to get these solved if possible so I can update TR1 for 1.35. As the problem apparently will be fixed with the next release of that compiler (see follow-up on boost.devel) and the diagnostic message tells us as much as "compiler crashes for uncertain reasons" it might be a reasonable option to switch to the old Boost.Tuple implementation for this compiler version.

Regards, Tobias