Antony Polukhin wrote:
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.
You are right that changing the implementation in this way can break some code in the future. Maybe we should be more conservative. The library has already a namespace boost::numeric so what about boost::numeric::convert_to/convert instead? Best Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/numeric-cast-tp3602499p3617618.html Sent from the Boost - Dev mailing list archive at Nabble.com.