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

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-20 18:02:46

"Fernando Cacciola" <fernando_cacciola_at_[hidden]> 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