Re: [Boost-users] [review] Fusion review

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-05-05 06:18:25

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<I, T>.

result_of::deref returns the exact type returned by deref(i)
                  its purpose is mainly to be able to write
                  forwarding functions that call deref(i).
                  deref(i) may or may not add a reference to the
                  actual type in the sequence (e.g. for efficiency--
                  vector iterator returns a reference,
                  mpl sequence iterator returns a value).

IOTW, it is not possible (or at least awkward) to write
forwarding functions with result_of::value_of alone.

> 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