old_numeric_cast and Borland 5.6.4
Hi, According the a recent status report, consersion/cast_test.cpp is still failing for Borland 5.6.4 The report details shows that the implementation is not being redirected to the old code, as it should for this compiler, even though this line: #if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564) # include<boost/numeric/conversion/detail/old_numeric_cast.hpp> #else is supposed to do that? Isn't 0x564 the version macro number for this compiler? Any ideas? TIA Fernando Cacciola
Fernando Cacciola wrote:
According the a recent status report, consersion/cast_test.cpp is still failing for Borland 5.6.4 The report details shows that the implementation is not being redirected to the old code, as it should for this compiler, even though this line:
#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564)
# include<boost/numeric/conversion/detail/old_numeric_cast.hpp>
#else
is supposed to do that?
Isn't 0x564 the version macro number for this compiler?
Any ideas?
That is the correct version number, but shouldn't the test be BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) Assuming Borland produce another compiler, let's not make the assumption they also fix this bug! (although we live in hope ;?) -- AlisdairM
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> escribió en el mensaje news:d9pfcd$pc8$1@sea.gmane.org...
Fernando Cacciola wrote:
[SNIPPED] Isn't 0x564 the version macro number for this compiler?
Any ideas?
That is the correct version number, but shouldn't the test be
BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
IIUC that produces the workaround to be activated even for earlier versions of the Borland compiler, but 5.5.1 in particular handles the code very well (in fact, I developed the library in that compiler). Best Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> escribió en el mensaje news:d9pfcd$pc8$1@sea.gmane.org...
Fernando Cacciola wrote:
[SNIPPED] Isn't 0x564 the version macro number for this compiler?
Any ideas?
That is the correct version number, but shouldn't the test be
BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
IIUC that produces the workaround to be activated even for earlier versions of the Borland compiler, but 5.5.1 in particular handles the code very well (in fact, I developed the library in that compiler).
Really? How sad for Borland! Well, BOOST_WORKAROUND(__BORLANDC__, > 0x551) && BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) ) Looks like what you need, then. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
"AlisdairM" <alisdair.meredith@uk.renaultf1.com> escribió en el mensaje news:d9pfcd$pc8$1@sea.gmane.org...
Fernando Cacciola wrote:
[SNIPPED] Isn't 0x564 the version macro number for this compiler?
Any ideas?
That is the correct version number, but shouldn't the test be
BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
IIUC that produces the workaround to be activated even for earlier versions of the Borland compiler, but 5.5.1 in particular handles the code very well (in fact, I developed the library in that compiler).
Really? How sad for Borland!
Indeed! I've been using Borland compilers since Turbo C 1.0 but because of the lastest versions I ended up switching to Visual (7.1).
Well,
BOOST_WORKAROUND(__BORLANDC__, > 0x551) && BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
Looks like what you need, then.
Ya, that's it. Txs Fernando Cacciola SciSoft
AlisdairM wrote:
Fernando Cacciola wrote:
According the a recent status report, consersion/cast_test.cpp is still failing for Borland 5.6.4 The report details shows that the implementation is not being redirected to the old code, as it should for this compiler, even though this line:
#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564)
# include<boost/numeric/conversion/detail/old_numeric_cast.hpp>
#else
is supposed to do that?
Isn't 0x564 the version macro number for this compiler?
Any ideas?
That is the correct version number, but shouldn't the test be
BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
Assuming Borland produce another compiler, ...
Careful, here -- they did! Well, that is one with a higher version number ;-) Latest official BCC shipped with BuilderX: __BORLANDC__ == 0x565 Latest Builder6 upgrade pack: __BORLANDC__ == 0x564 Kylix (didn't verify it myself - source: Boost.Config): __BORLANDC__ == 0x570 It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up). Regards, Tobias
Tobias Schwinger <tschwinger@neoscientists.org> writes:
AlisdairM wrote:
Fernando Cacciola wrote:
That is the correct version number, but shouldn't the test be
BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
Assuming Borland produce another compiler, ...
Careful, here -- they did! Well, that is one with a higher version number ;-)
Latest official BCC shipped with BuilderX:
__BORLANDC__ == 0x565
Latest Builder6 upgrade pack:
__BORLANDC__ == 0x564
Kylix (didn't verify it myself - source: Boost.Config):
__BORLANDC__ == 0x570
It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up).
Why test for below 0x600? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
AlisdairM wrote:
Fernando Cacciola wrote:
That is the correct version number, but shouldn't the test be
BOOST_WORKAROUND( __BORLANDC__, BOOST_TESTED_AT( 0x564) )
Assuming Borland produce another compiler, ...
Careful, here -- they did! Well, that is one with a higher version number ;-)
Latest official BCC shipped with BuilderX:
__BORLANDC__ == 0x565
Latest Builder6 upgrade pack:
__BORLANDC__ == 0x564
Kylix (didn't verify it myself - source: Boost.Config):
__BORLANDC__ == 0x570
It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up).
Why test for below 0x600?
A pessimist guesstimation based on the tremendous ammount of bugfixes in the recent past ;-) (excuse my sarcasm)...
Tobias Schwinger <tschwinger@neoscientists.org> writes:
It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up).
If the highest released Borland compiler is 0x570, why do you suggest testing for "below 0x600"? Rounding up may inadvertantly include future compilers that don't need such workarounds. -- Chris
Chris Uzdavinis wrote:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up).
If the highest released Borland compiler is 0x570, why do you suggest testing for "below 0x600"? Rounding up may inadvertantly include future compilers that don't need such workarounds.
There was a (much more compliant preview) version 0x600, once... And AFAIK 0x565 was released /after/ 0x570. Btw. I have 5.6.5 installed, in case someone needs testing.
Chris Uzdavinis <chris@uzdavinis.com> writes:
Tobias Schwinger <tschwinger@neoscientists.org> writes:
It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up).
If the highest released Borland compiler is 0x570, why do you suggest testing for "below 0x600"? Rounding up may inadvertantly include future compilers that don't need such workarounds.
Our standard practice is to keep the workaround in place for future versions using BOOST_TESTED_AT(), which tends to ensure that library code doesn't break when a user gets a new compiler and also gives us a way to locate all workarounds that can be limited to earlier versions when a later version comes out. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Our standard practice is to keep the workaround in place for future versions using BOOST_TESTED_AT(), which tends to ensure that library code doesn't break when a user gets a new compiler and also gives us a way to locate all workarounds that can be limited to earlier versions when a later version comes out.
That makes a lot more sense than testing that we're under some non-existant compiler version. Thanks. -- Chris
Tobias Schwinger wrote:
Careful, here -- they did! Well, that is one with a higher version number ;-)
Latest official BCC shipped with BuilderX:
BORLANDC == 0x565
Thanks, had not realised they increased the version number of the compiler, I was only aware of linker fixes.
Latest Builder6 upgrade pack:
BORLANDC == 0x564
OK, now we're in agreement <g>
Kylix (didn't verify it myself - source: Boost.Config):
BORLANDC == 0x570
Oops, keep forgetting about that one! Trouble is, no-one appears to be testing with it, or at least, it does not show on the Boost regression test lists. I would be very reluctant to use BOOST_TESTED_AT with a higher version than was actually tested!!! IIUC, the workaround is still applied when using BOOST_TESTED_AT, regardless of compiler version. However, if you #define BOOST_DETECT_OUTDATED_WORKAROUNDS you will get a warning for every BOOST_TESTED_AT which gives a lower version, so that you can turn it into a more definite <= test one the bug is fixed, or raise the version number to recognise the latest testing.
It seems all are pretty close in terms of portability (for the former two I know it and for Kylix it's another guess reading Boost.Config), so testing for below 0x600 is what you want, I guess (and above 0x551, reading the follow-up).
0x600 seems to be Borland's version series for the EDG-front end they were experimenting with. As I understand, those experiments are on hold now, so we may see future compilers with versions > 0x565 and < 0x600. Remember the EDG front end was only ever a preview, not a supported, released product. It does make life tough library writers though! AlisdairM
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
Hi,
According the a recent status report, consersion/cast_test.cpp is still failing for Borland 5.6.4 The report details shows that the implementation is not being redirected to the old code, as it should for this compiler, even though this line:
#if BOOST_WORKAROUND(BOOST_MSVC, < 1300) || BOOST_WORKAROUND(__BORLANDC__, == 0x564)
# include<boost/numeric/conversion/detail/old_numeric_cast.hpp>
#else
is supposed to do that?
Yes. I'm sure the report is just out-of-date. But why are you testing for the exact version 0x564? I'm sure 5.5.1 is also broken. Do you know that 5.6.5 (or whatever) won't also be broken? If not, you want BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x564)) Didn't I already post something about that a couple days ago? -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:ubr5rzhat.fsf@boost-consulting.com...
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
Hi,
is supposed to do that?
Yes. I'm sure the report is just out-of-date.
OK
But why are you testing for the exact version 0x564? I'm sure 5.5.1 is also broken.
But it isn't. 5.6.4 shipped with a different std library (w.r.t 5.5.1) and there lies the problem (numeric_limits<> not having compile time constants) In fact, I developed the entire library using 5.5.1, so I'm pretty sure it works (and if the current version doesn't becasue of some recent change is definitely fixable). I have not tried bjam with my local 5.5.1 version to check it passes ALL of the tests (since bcc5.5.1 is not in the satus report anyway), but I'm sure this compiler doesn't need the old cast code. Fernando Cacciola SciSoft
Fernando Cacciola wrote:
But it isn't. 5.6.4 shipped with a different std library (w.r.t 5.5.1) and there lies the problem (numeric_limits<> not having compile time constants)
Hmmm. My problem was nothing to do with compile time constants, but that the compiler does not support default template parameters for nested templates. I believe that is a problem with 5.5.1 as well. Maybe I'm looking at the wrong examples / test cases? AlisdairM
"Alisdair Meredith" <alisdair.meredith@uk.renaultf1.com> escribió en el mensaje news:d9r36i$m8b$2@sea.gmane.org...
Fernando Cacciola wrote:
But it isn't. 5.6.4 shipped with a different std library (w.r.t 5.5.1) and there lies the problem (numeric_limits<> not having compile time constants)
Hmmm. My problem was nothing to do with compile time constants, but that the compiler does not support default template parameters for nested templates. I believe that is a problem with 5.5.1 as well.
Maybe I'm looking at the wrong examples / test cases?
Hmmm, maybe... Can you show me a compiler output? TIA Fernando Cacciola SciSoft
participants (6)
-
Alisdair Meredith -
AlisdairM
-
Chris Uzdavinis -
David Abrahams -
Fernando Cacciola -
Tobias Schwinger