|
Boost : |
From: Richard Peters (r.a.peters_at_[hidden])
Date: 2005-03-05 13:34:22
From: "Rob Stewart" <stewart_at_[hidden]>
> From: "Richard Peters" <r.a.peters_at_[hidden]>
> >
> > The bigint type proposed for the C++ standard library does not permit
the
> > use of expression templates. Using expression templates has a positive
and a
> > negative aspect: A significant speedup can be gained using expression
> > templates. The downside is that templates cannot deduce the correct type
of
> > expressions, for example:
> > template<class T> void f(T a, T b) will not work when invoked as f(x +
y,
> > x - y), because x + y returns an object of type different from x - y.
> > Because the C++ standard library proposal specifies the result type of
the
> > operators to be of type const integer, a library implementing that
proposal
> > cannot use expression templates.
>
> PMFJI, but I wonder whether this would work:
PMFJI... I have no clue what it means, sorry.
> template <typename T, typename U>
> void f(T a, U b)
> {
> typedef typename <magical_incantation<T, U>::type V;
> f_impl<V>(a, b);
> }
>
> a and b can have different types, but then magical_incantation
> computes a common type to which both can be converted and the
> implementation function can be invoked with that type.
>
> I may be off base, and you may have already tried this approach,
> but I just wanted to mention it if it could help.
Oh, there are a few ways in which you can perform computations with the
expression templates, but that was not what I meant. My point was: If you
specify the result of operators + and - to be big_integer, then expression
templates cannot be made to work, because then those operators return types
other than big_integer. User code may depend on the specification that those
operators do return big_integers. Therefore, any implementation satisfying
the requirements of the C++ standard library proposal will miss the possible
speedincrease gained by the use of expression templates.
best regards,
Richard Peters
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk