From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-11-21 13:27:13
On Nov 22, 2007 12:35 AM, Giovanni Piero Deretta <gpderetta_at_[hidden]> wrote:
> On 11/20/07, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> > On Nov 20, 2007 12:37 AM, Giovanni Piero Deretta <gpderetta_at_[hidden]>
> > > [...]
> > > This doesn't return the right thing with non const parameters. A very
> > > simple result_of compatible wrapper around fusion::at_c will do. In fact
> > > I think that fusion should provide function objects for every one of its
> > > algorithm.
> > >
> > You mean:
> > std::pair<int, int> pair(1, 2);
> > std::cout << boost::select<1>()(pair) << std::endl; // should output 2
> > ?
> > I think I'm missing something here... Can you elaborate?
> In fact I was wrong. Now I do not think it return the right thing even
> with const parameters :). The problem is that you always return a
> copy of the Nth element (as a temporary). This work fine if you only
> need read access *and* the object is small. In this example 'select'
> copy the vector at every extraction!
> std::map<int, std::vector<int> > map = ....;
> void foo(std::vector<int> const&);
> std::for_each(map.begin(), map.end(), bind(foo,
> bind(boost::select<1>(), _1)));
> If you remove the const from the signature of foo, the example won't
> compile at all. It is a bit elaborate to deduce the return value of a
> generic tuple accessor in the most general case possible, but it can
> be done. Anyways, fusion at_c already takes care of all the work.
Ah, you're referring to const-correctness and not returning a reference instead.
In this case, I agree that this isn't acceptable in a lot of cases,
thanks for pointing it out.
Would it help if the current version of select<> would be called
select_copy<> and select<> would return a correctly const-qualified
I've also tried going with fusion::at_c in my initial attempt to get
the correct result type, only that I run into problems with const
correctness. I'll try my hand at it some other time though.
Thanks for the elaboration!
-- Dean Michael C. Berris Software Engineer, Friendster, Inc. [http://cplusplus-soup.blogspot.com/] [mikhailberis_at_[hidden]] [+63 928 7291459] [+1 408 4049523]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk