"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
[SNIPPED]
It used to work a few days ago (ca. 2-4). If this is not something obvious I could try to find out which CVS commit lead to the regression.
Well, it's complaining that unsigned long long is not a numeric type.
I can't for the life of me understand why boost::numeric_cast is still hanging around in cast.hpp when we have another one (that actually works!) in boost/numeric/conversion/cast.hpp. This seems like fodder for ODR violations. Fernando, what's up with this? Why haven't you replaced the one in cast.hpp with an #include?
I've never got to silently replace the old numeric_cast becasue mine is totally unusable with VC6, BC5.6.4 and gcc2.92 I've always planned to get it to work with those compilers, but I never had the time :-)
But it's been a long long time now (wow)... So I better do something about it.
I see 3 options here:
(1) Keep to old code and use it as a fallback implementation for broken compilers (simplest)
Fine with me.
(2) Try to fix the new code for those compilers (hardest)
2b. You could "fix" it by inserting the old code as a workaround. At least it would all be in the same place then.
(3) Just remove the old cast code and redirect the include to the new one (having broken compilers stop working)
Since (the old) numeric_cast<> is currently working (at least to some extent) with those compilers, and there can still be users around (specially bcc5.6.4), (3) is just not an option I think.
Agree.
I only has access to bcc5.6.4 so I can make this one work, but I can't fix the code for VC6 and gcc2.92 as I don't have them here.
Although the new library has many options and features, the new numeric_cast<> is just a checked static_cast<>, and the new library is better there only in that it checks more reliably; therefore, I guess (1) is good tradeof given this point in the release.
(Part of the reason the old code works with broken compilers but not the new one is because the old code uses a custom version of numeric_limits for broken libraries... the new code just doesn't and I prefered to have such fixes elsewhere (like in limits.hpp))
What do you think?
I like 2b. -- Dave Abrahams Boost Consulting www.boost-consulting.com