Boost logo

Boost :

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk