From: Andy Little (andy_at_[hidden])
Date: 2006-04-01 19:42:30
"Alexander Nasonov" wrote
> Andy Little wrote:
>> I'm interested to know in what situations the promotion_traits libarary is
>> to be used? I looked at the standard and I see that it seems to follow that,
>> but in practise the only similar situation of needing to know promotion rules
>> my own code was in choosing the type that the input types are to be converted
>> in some operation.
> Are you talking about _usual arithmetic conversions_?
I am talking about usefulness. In what practical situation is promotion_traits
likely to be used? Put it another way. What is the rationale for
> I like fine granular model. Since usual arithmetic conversions depend on
> integral promotion, it's logical to implement integral_promotion fisrt.
> BTW, LibrariesUnderConstruction has a reference to
> types_promotion_traits developed by Aleksey Gurtovoy.
> Is arithmetic_conversions_traits<> defined there what you need?
IMO All this has recently been superceded by Boost.Typeof.
>> I am surprised to see that input parameters unrelated to promotion are
>> to pass unchanged to the output.The example given is e.g
>> Expression ---> Result
>> floating_point_promotion<int const>::type ---> int const
>> I would expect, rather, to have a compilation failure in case of an invalid
> I prefer promote-if-possible because it follows a semantic in the
> standard. For example, integral promotions can be applied when passing
> an argument to printf-like function. If integral promotions can't be
> applied to the argument, nothing happens.
> If you want to check whether promotion has an effect you can write
> is_same< T, promote<T>::type >::value.
It might help to show useage examples to decide the behaviour, but is it not
generally better to constrain a functions input to only those types for which
its functionality is meaningful? If you want to widen the behaviour to accept
other types you can use mpl::eval_if for example.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk