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