|
|
Ublas : |
From: Michael Stevens (mail_at_[hidden])
Date: 2005-07-13 04:48:30
On Saturday 09 July 2005 03:47, Ian McCulloch wrote:
> Michael Stevens wrote:
> > Interesting solution using a 3rd party for traits. If I understand it
> > correctly it only works for a known and limited set of expressions for
> > which you can predefine the traits.
>
> No, I don't think so: the logic for computing types needs to move into the
> traits class too. Do you have an example in mind where this could not be
> done?
Ian thanks for the reply. I have thought a little more and this should make
things clearer.
My case comes from the wish to provide some common functions into the uBLAS
expression template hierarchy.
When I use
struct foo : public expression<foo>
{
typedef int size_type;
};
I would be NICE to inherit a bunch of functions whose parameters depend on
size_type. Because 'foo' is incomplete in the definition of the template this
cannot be done.
Interestingly it not necessary for a type to be complete to define a member
function whose signature depends on it. In the case of the expression class
template <class E>
struct expression {
typedef E expression_type;
void expression_function (expression_type);
void size_function (typename expression_type::size_type);
The expression_function can be defined but the size_function cannot! Both are
incomplete.This dichotomy makes me hopeful that there is some trick.
If E can only be a small number of possible types hen one could use a
separately specialised trait for each case. This was how I (mis)interpreted
your solution.
The correct solution is to use an extra template argument thus.
struct foo : public expression<foo, int>
template <class E, class S>
struct expression {
typedef E expression_type;
void expression_function (expression_type);
typedef S size_type;
void size_function (size_type);
I the case of uBLAS I am reluctant to use this as it has a significant effect
on the existing syntax. So I am still looking for a trick!
Cheers,
Michael