Re: [boost] [functional] Generic Selector for STL Pair's and Boost.Tuple's

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2007-11-21 14:50:46

On Nov 22, 2007 3:01 AM, Giovanni Piero Deretta <gpderetta_at_[hidden]> wrote:
> On Nov 21, 2007 7:27 PM, Dean Michael Berris <mikhailberis_at_[hidden]> wrote:
> > On Nov 22, 2007 12:35 AM, Giovanni Piero Deretta <gpderetta_at_[hidden]> wrote:
> > >  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
> > reference instead?
> >
>
> I do not think so. There is no reason not to make select as general as possible.
> Really, having select work in all cases is
> not that hard. Implementing it is a good exercise in metaprogramming.
> Start by looking at how boost::tuples::get computes its return value.
>

That being said, the rationale for select<> are the following:

1. It's a generalization of the select1st and select2nd SGI extensions
to the STL, intended to work at least with Boost.Tuple's (tr1::tuple
?) and STL Pairs.

2. This is intended to be really simple, and perhaps somehow made
self-contained and easy to factor out so that
    a) it doesn't pull in Fusion (which I absolutely think is an
excellent library, which I fortunately am able to use at work every
single day)
    b) it only pulls in the required MPL headers, which can even be
re-implemented in cases where having the MPL present is unacceptable
    c) it only relies on the presence of Boost Tuple (can be made
optional by doing some preprocessor checking) and STL pair's

So personally, I appreciate the feedback -- it's invaluable feedback
at that. But I'd like to be able to make it work by making it
self-contained; and if suddenly Joel et al decide to make all Fusion
functions (like at_c) be reflected as function objects as well (do I
hear Phoenix coming along to contain this? :D), then that's something
a lot of people would appreciate as well.

Precisely for people who don't have Fusion available, or don't want to
pull Fusion into the project, something simple is welcome: so I'll try
hard to make select<> not rely on Fusion to do the heavy lifting. ;-)

> > 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.
> >
>
> I've never really used Fusion in real programs (at work I'm stuck with an older
> fusionless boost), but it should be const correct. If you have found
> any bugs you
> shuld report them.

I have used Fusion in real programs and they work great. The bug about
const correctness which I'm talking about is described below, and has
nothing to do with Fusion.

> Doesn't something like this work?
>
[snip]
>
> Of course this is completely untested. I didn't even try to compile it.
>

So the idea is to use fusion::at_c<>() which I've been trying to avoid
precisely because this static assert will fail:

BOOST_STATIC_ASSERT((
  boost::is_same<
    boost::result_of<select<0>(std::pair<int, int>)>::type,
    int
  >::value
));

This I think is because Fusion's at_c<>::type will return 'int const
&' which is correct behavior as far as fusion goes, but not what I
intend with the current implementation of select<> which is to return
copies and not references. Perhaps it's going to be good to rethink
this decision, and come up with select<> and select_copy<>.

I'll get back to this when time permits. Thanks for the feedback!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://cplusplus-soup.blogspot.com/]
[mikhailberis_at_[hidden]]
[[phone]]
[[phone]]