Boost logo

Boost :

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

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

> "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?

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

> 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.


> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at