"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"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?
You say you're talking about "operations not types", but I think you're just mystifying something that's simple. Whether or not multiplication is commutative depends entirely on the types of its operands.
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.
And neither should that trait be glommed into the one used for determining result types.
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...
Depending on who "we" is, yes we do. At least I do. Ask Greg Colvin for my is_modable implementation.
we're long gone. ConceptChecking helps the user interface part.
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.
Sure.
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's a fact.
It would be useful to test to find out how well this works in practise. Results on gcc3.2 have not been encouraging.
Maybe a compiler bug?
3) typeof, decltype etc is not standard C++ as it stands. Its a non-starter.
Not neccessarily. We can build a pretty nice typeof replacement that requires just a little help from users.
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.
Nope, I wasn't giving you any advice. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com