"David Abrahams" <dave@boost-consulting.com> wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote
For example a multiplication maybe commutative in one context, but not in another.
What constitutes context other than the argument types involved?
* is not a context ,{ a * b} is a context. What more do you need? What more have I implied?
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.
I found output of (say) operator + as "+" useful in following the execution of expression templates. "super-functional" is an off-the-cuff replacement for <functional>. Dont take it too seriously, but std::plus etc are past their best. If I wish to know whether an operation on two types is commutative, I might like to be able to quiz the operation about it. decltype wont do that for 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.
The compiler does. We dont... we're long gone. ConceptChecking helps the user interface part.
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.
I need some way to get information about the result types of my value_types operation. eg What results form mux of a interval<double> and a double. result_of is ok as far as it goes. but 1) There needs to be a common name for Op ie operator_XX or whatever. Otherwise we will all be carrying on our merry own way. That is the status quo. 2) In theory result_of is specializable for functors. It would be useful to test to find out how well this works in practise. Results on gcc3.2 have not been encouraging. 3) typeof, decltype etc is not standard C++ as it stands. Its a non-starter. Therefore if I understand it correctly your advice to me is to wait for decltype to be in the standard? OTOH point me at the specs answering the above. -------- What is The new version of MTLs take on UDT value_types. Or is it to be any colour you like as long as its double? To be generic it should of course support my physical-quantities type... with one common interface . ;-) regards Andy Little