[boost] Re: result_ofOp, operator should be a template parameter

From: David Abrahams (dave_at_[hidden])
Date: 2004-07-06 04:38:11

"Andy Little" <andy_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote
>> Joel de Guzman <joel_at_[hidden]> writes:
>> > Doug Gregor wrote:
>
>> >>     result_of<Op(A, B)>::type
>> >
>> > I think this is the best interface I've seen so far. The result_of_plus
>> > is just a temporary solution while waiting for Doug's result_of work
>> > which was not available at the time.
>>
>> ...which is just a temporary solution while we wait for decltype?
>
> Apologies, its not clear from the subject. I am referring to operations,
> which have more attributes than just the type of the result.
>  For example a multiplication maybe commutative in one context, but not in
> another. 

What constitutes context other than the argument types involved?

> This sort of information  could be used by an optimizer walking
> about in an expression template for example.

I think most of us are very well aware of uses for result type
detection.

> stream output of the symbol for the particular operator provides a simple
> way of debugging in generic code. A "super-functional" functor with
> specialisable traits  would provide a common mechanism for specializing
> operations for UDT's. 

That part is all incomprehensible to me.

> IOW A way for the UDT designer to communicate their
> intent to users of operations on their types and how they interact with
> other types. At the simplest level for example, communicating whether an
> operation between two types from different libraries is supported. 

Provided that's the same question as "is there an overload that will
match these arguments", we already know how to detect that without
any user intervention.

> So there is more to it than just decltype. I am talking about
> operations rather than types after all.

The right thing to do is for overloads to be written to operate only
on appropriate combinations of types, IMO.  Then you don't need a
"super-functional functor" or whatever.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com