David Abrahams wrote: I'll try to reply to some of Dave's comments here. I think it's better if I do it a part at a time starting with design.
- What is your evaluation of the design?
It's very good overall.
I find the dispatching and function selection mechanisms cumbersome and inelegant, but I'm not sure if there's a better solution. Maybe since usually iterator intrinsics have to be implemented all together, it would be best to allow them to be defined in one big class template, rather than being forced to piecemeal create a bunch of little nested templates.
That's a possibility. One advantage of that approach is that we can subclass from a "facade" class that implements most of the basic infrastructure whereby limiting the things that are needed to be implemented. It might also be a good idea to implement some form of iterator adapters. I'll spend some time thinking about that. I think a similar approach might also be useful for implementing the sequence intrinsics and correspondingly, the view adapters.
I'm a bit surprised to see static call() functions used instead of operator() for the implementation of a function call, and also to see the use of nested apply<> metafunctions for computing the result types of functions. I thought Joel had decided to use something compatible with boost::result_of.
Well, I think we already have that covered in our chat a while ago. Anyway, the answer is that: unlike Fusion1, Fusion2 algorithms are not objects. Fusion1 used to have algorithm objects which are basically functors. This is not the case for Fusion2. One reason is because of the need to have the syntax: at_c<N>(x) or find<T>(x), etc. If at_c was an object, the interface would have to be at_c<N>()(x). We can get away with that, but we definitely can't get away with get<N>(x), which is part of the TR1 interface.
I'm surprised and a little concerned about what I perceive to be redundancy in the value_of metafunction and the deref_impl metafunction class.
result_of::value_of returns the actual type in the sequence
it is analogous to tuple_element
In the extension example, I see repeatedly the same patter transferring the cv-ref qualification from one type to another. Can't that be made simpler for extenders?
typedef typename mpl::if_< is_const<Sequence>, std::string const&, std::string&>::type type;
Can you point me to an example in the library, please? Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net