|
Boost : |
From: Jeremy Siek (jsiek_at_[hidden])
Date: 2001-03-29 12:18:39
On Thu, 29 Mar 2001, Ullrich Koethe wrote:
koethe> I don't see why the result traits shouldn't be part of the algebraic
koethe> concept definitions. After all, you always need them together.
Oh, I didn't mean that I wouldn't add them to the requirements. I just
meant that I'd apply the current language about convertibility, etc. to
the type produced by the traits.
koethe> > To allow for expression templates, the result type will not only
koethe> > depend on the operands but also on the operator. Therefore we
koethe> > need a tag for each operator.
koethe> >
koethe> > struct add_tag { };
koethe> > struct multiply_tag { };
koethe> > ...
koethe> >
koethe> > and then make the operator tag a parameter to the traits class
koethe> >
koethe> > result_traits<OpTag,A,B>::type
koethe> >
koethe>
koethe> Can you give examples where this would be necessary? I've contemplated
koethe> this in my application domain, but it looked like an
koethe> over-generalization.
As I said above, this is required by expression templates. Look at
Walter's matrix code. When you add two matrices you get one type, and when
you subtract them you get a different type. This is because the function
being applied has to be encoded in the expression type, so that later on,
when the expression is evaluated in the assignment, the operations can be
performed.
Cheers,
Jeremy
----------------------------------------------------------------------
Jeremy Siek www: http://www.lsc.nd.edu/~jsiek/
Ph.D. Candidate email: jsiek_at_[hidden]
Univ. of Notre Dame work phone: (219) 631-3906
----------------------------------------------------------------------
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk