Boost logo

Ublas :

From: Matthias Schabel (boost_at_[hidden])
Date: 2007-03-28 17:27:07


> The implementation of type deduction of uBLAS is really
> complicated, so
> we are still looking for a simpler version. The use of result_type of
> operator+ was already a big advantage. However the current
> implementation assumes that all operation (+,-,*,/) follow the same
> rules. A modification of this assumption would mean a big redesign of
> many classes. Any help is welcome.

Why is type deduction complicated? Is there some reason to not obey
the rules followed by the compiler itself? You might want to look at
the header operators.hpp in the proposed Boost.Units library in the
Vault (mcs_units_v0.7.2.zip) - this file contains all the type
deduction needed for this library, and the type operations needed for
compile-time dimensional analysis have to be much more complex than
those in ublas. Even if you don't have typeof support, it is possible
to simply define the following helper classes specialized for the
supported built-in types (if a bit tedious) :

template<typename X> struct unary_plus_typeof_helper;
template<typename X> struct unary_minus_typeof_helper;

template<typename X,typename Y> struct add_typeof_helper;
template<typename X,typename Y> struct subtract_typeof_helper;
template<typename X,typename Y> struct multiply_typeof_helper;
template<typename X,typename Y> struct divide_typeof_helper;

template<typename X,typename Y> struct power_typeof_helper;
template<typename X,typename Y> struct root_typeof_helper;

so

template<> struct add_typeof_helper<int,double> { typedef double type; }

etc... Then all operators return the appropriate type :

template<class X,class Y>
typename add_typeof_helper<X,Y>::type
operator+(const ublas<X>&,const ublas<Y>&);

Deduction in expression templates should just happen correctly if
they are implemented correctly, since you should just get :

(x+y)*z -> multiply_typeof_helper< add_typeof_helper<X,Y>::type,Z>::type

I have implemented this in my own array library with relatively
little difficulty.

Matthias