"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
Joel de Guzman <joel@boost-consulting.com> 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