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

From: Joel de Guzman (joel_at_[hidden])
Date: 2007-11-21 17:35:09

Dean Michael Berris wrote:

> 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.

That's a good rationale. I suggest:

1. write lotsa tests around it
2. write it first using fusion
3. write it without fusion, making sure all tests pass
4. ifdef out fusion and/or mpl code
    -- give the user a chance to choose. there will be cases when
       fusion *is* available and your code becomes redundant.

Regards,
-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net