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

From: Andy Little (andy_at_[hidden])
Date: 2004-07-06 09:53:32

"David Abrahams" <dave_at_[hidden]> wrote
> "Andy Little" <andy_at_[hidden]> writes:
> > "David Abrahams" <dave_at_[hidden]> 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