[boost] Re: Re: Re: Proposal: type-promoting arithmetics forderivativetypes

From: Max Motovilov (max_at_[hidden])
Date: 2004-02-26 10:33:29

"Brian McNamara" <lorgon_at_[hidden]> wrote in message
news:20040226082809.GC3173_at_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...