2011/6/22 Brandon Kohn <blkohn@hotmail.com>:
The defaults of numeric_cast_traits definition conform to the current behavior. It would only change if the users customize it. From that angle I think the greater flexibility comes with a bit more responsibility on the users side. Seems like a fair trade-off to me.
Well, then here is some ideas. I am really afraid that some user will define such trait in header file. Then all the code above the included header file will use the old conversion trait, and below - the new trait. Include files became dependent from their order. It is really error prone. User can forget about the trait, change the inclusion order and get some really hard detectable errors. So it would be more save not to modify the behavior of boost::numeric_cast<N>(x) function, but rather create function with some other name, for example boost::numeric_traited_cast<N>(x) and create a separate namespace in boost::numeric for the traits. It would be better not to return converter()(arg); but return converter::convert(arg);. It won`t call the constructor of the converter and give better performance on some old/bad compilers. Best regards, Antony Polukhin