"Brian McNamara" <lorgon@cc.gatech.edu> wrote in message news:20040226082809.GC3173@lennon.cc.gatech.edu...
Is there a way to avoid
template<... template< typename _ > class DAT >
? While I don't know a class like this offhand, I can imagine a class that's typically instantiated along the lines of
SomeClass<Foo,float> SomeClass<Foo,double> SomeClass<Bar,float> SomeClass<Bar,double>
and it would be swell if the "DAT" technique generalized so that you could specify that you wanted to DAT-ify
SomeClass<Foo,_1>
I believe I understand your intent. My intent though was to simplify defining arithmetics for types that ARE relatively straightforward templates and do not involve FP concepts at all in their definition. It is probably possible to do both using the same or similar mechanism. I'm not sure if I like the idea of having to refactor DAT<T> to something else first, even if it were done using a well-established library such as MPL. Upon reflection (forced keyboard withdrawal does wonders ;) ) the value of what you're proposing started to dawn on me. Let's say we have a policy-based DAT, Foo< T, Policy >. It still behaves as a DAT in respect to its first template parameter but it will not match the "temlpate< typename _
class" pattern. Were it re-factored as Wrap< Foo, _1, Policy > it might be easier to fit into a common infrastructure.
The problem though ts that there doesn't seem to be a way to match "template< typename _1, ... typename _N > class" - type arguments against a single template parameter. So we'll have to end up with your scheme:
template <class X, class Y> // enable_if both X and Y "isa" DAT (of the same kind) // based on specialization of result_xxx traits, deduce what was // called T1/T2 before operator+( const X& x, const Y& y ) { ... }
along with an extensive library of facilities providing "trait definition by empty template specialization" (hey, another weird acronim is coming up...) Which might not be so bad after all, except for the fact that the operators we inject are now as generic as can be (mine were at least limited to SomeTemplate<T> arguments), with only SFINAE to protect us from mayhem... Oh well, if only someone came up with the idea how NOT to put those operators into global namespace by virtue of a header file inclusion... Regards, ...Max...