"Alexander Nasonov" wrote
Andy Little wrote:
Hi,
I'm interested to know in what situations the promotion_traits libarary is meant 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 in my own code was in choosing the type that the input types are to be converted to 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 promotion_traits?
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. http://tinyurl.com/4kvla 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 allowed 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 parameter?
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. regards Andy Little