Re: [boost] [mpl][tru64cxx] set failing

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-06-20 07:43:03

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)
(2) Try to fix the new code for those compilers (hardest)
(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.
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?

Fernando Cacciola
SciSoft

P.S.: Thank you David for the private prompt. Two weeks ago our second son 
was born and I'm just now getting back to work life so I totally missed this 
:-)