Boost logo

Boost :

From: Pavel Chikulaev (pavel.chikulaev_at_[hidden])
Date: 2005-03-07 15:17:48


"Jonathan Turkanis" <technews_at_[hidden]> wrote in message
news:d0iarn$gpf$1_at_sea.gmane.org...
> What about templates with more than one parameter:
>
> template<typename U, typename V>
> LAZY_OP(Matrix_ + Matrix__<U, V>()); // unprotected comma

Right now I can tell you only one solution:
template<typename U, typename V>
LAZY_OP((Matrix_ + Matrix__<U, V>()));
How do you like it?

>>> Also, I believe Fusion (the sucessor to Tuple) would be a valuable
>>> tool.
>> Is it (same as)(old version of) Tuple?
>
> No. (What would be the point, then?) It provides extensible tuple-like
    Oops. My bad - bad english.
> sequences, together with a collectin of algorithms and adapters, similar
> to MPL.

I've not looked at Fusion's algorithms but I'm pretty sure that it won't
help me with parsing operators tree and choosing the most conforming
lazy operator.

> I think it's not documented, but last time I looked at it, the design was
> close
> enough to MPL that if you knew MPL and Tuple it would be easy to start
> using.
>
> The reason I though Fusion would be relevant is that in an expression
> template
> library, the information about a complex expression that you need to
> maintain in
> order for it to be evaluated once it is complete is:
>
> 1. A list of all the concrete objects which particpate in the expression
> 2. The structure of the expression.
>
> Fusion may provide the infrastructure for this. In the iostreams library,
> I used
> something like a homemade tuple; but for a more ambitious implementation
> of
> expression templates I would want to use existing tools as much as
> possible.

I've used in my library home-made

template<typename FirstArgT, typename Op, typename SecondArgT>
class binary_op;

template<typename Op, typename ArgT>
class unary_op;

template<typename LazyExpr>
class result_of;

I don't think that Fusion will help me here, but I'll take a look at it.
Thanks.

--
Pavel Chikulaev
 

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