Re: [boost] [mpl][tru64cxx] set failing
Hi Dave ----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Sábado, Junio 18, 2005 9:58 pm Asunto: Re: [boost] [mpl][tru64cxx] set failing
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
mpl::set is currently failing
Because the component is broken and I checked in a testcase that shows it to be broken.
I don't think this has to do with your newly checked testcase: the problem also shows outside MPL test suite: http://tinyurl.com/8vdtj Besides, last COMSOFT regression cycle is older than your commit. Joaquín M López Muñoz Telefíonica, Investigación y Desarrolo
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
Hi Dave
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Sábado, Junio 18, 2005 9:58 pm Asunto: Re: [boost] [mpl][tru64cxx] set failing
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
mpl::set is currently failing
Because the component is broken and I checked in a testcase that shows it to be broken.
I don't think this has to do with your newly checked testcase: the problem also shows outside MPL test suite:
Besides, last COMSOFT regression cycle is older than your commit.
In that case I have no clue about this one. Well, I'm fixing the set problem Brian found now, anyway. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- David Abrahams <dave@boost-consulting.com> wrote:
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
Hi Dave
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Sábado, Junio 18, 2005 9:58 pm Asunto: Re: [boost] [mpl][tru64cxx] set failing
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
mpl::set is currently failing
Because the component is broken and I checked in a testcase that shows it to be broken.
I don't think this has to do with your newly checked testcase: the problem also shows outside MPL test suite:
Besides, last COMSOFT regression cycle is older than your commit.
In that case I have no clue about this one.
Well, I'm fixing the set problem Brian found now, anyway.
I am not sure this is related, but something bad happened recently. We the CVS from a few minutes ago I get: % cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DBOOST_DISABLE_THREADS -DNDEBUG -O2 -fast -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4.1_ticker_simple/include/python2.4 -c -o boost/libs/python/src/converter/builtin_converters.os /net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp cxx: Error: /net/legless/scratch1/rwgk/hot/boost/boost/cast.hpp, line 347: #94 the size of an array must be greater than zero detected during instantiation of "Target boost::numeric_cast<Target,Source>(Source) [with Target=unsigned long long, Source=long]" at line 204 of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/conve rter/builtin_converters.cpp" typedef bool result_must_be_numeric[result_traits::is_specialized]; --------------------------------------------^ cxx: Info: 1 error detected in the compilation of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp". 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. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> wrote:
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
Hi Dave
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Sábado, Junio 18, 2005 9:58 pm Asunto: Re: [boost] [mpl][tru64cxx] set failing
"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> writes:
mpl::set is currently failing
Because the component is broken and I checked in a testcase that shows it to be broken.
I don't think this has to do with your newly checked testcase: the problem also shows outside MPL test suite:
Besides, last COMSOFT regression cycle is older than your commit.
In that case I have no clue about this one.
Well, I'm fixing the set problem Brian found now, anyway.
I am not sure this is related,
It's not.
but something bad happened recently. We the CVS from a few minutes ago I get:
% cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DBOOST_DISABLE_THREADS -DNDEBUG -O2 -fast -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4.1_ticker_simple/include/python2.4 -c -o boost/libs/python/src/converter/builtin_converters.os /net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp cxx: Error: /net/legless/scratch1/rwgk/hot/boost/boost/cast.hpp, line 347: #94 the size of an array must be greater than zero detected during instantiation of "Target boost::numeric_cast<Target,Source>(Source) [with Target=unsigned long long, Source=long]" at line 204 of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/conve rter/builtin_converters.cpp" typedef bool result_must_be_numeric[result_traits::is_specialized]; --------------------------------------------^ cxx: Info: 1 error detected in the compilation of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp".
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? -- Dave Abrahams Boost Consulting www.boost-consulting.com
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 :-)
"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
With the latest CVS I am seeing this error again:
% cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DBOOST_DISABLE_THREADS -DNDEBUG -O2 -fast -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4.1_ticker_simple/include/python2.4 -c -o boost/libs/python/src/converter/builtin_converters.os
/net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp
cxx: Error: /net/legless/scratch1/rwgk/hot/boost/boost/cast.hpp, line 347: #94 the size of an array must be greater than zero detected during instantiation of "Target boost::numeric_cast<Target,Source>(Source) [with Target=unsigned long long, Source=long]" at line 204 of
"/net/legless/scratch1/rwgk/hot/boost/libs/python/src/conve
rter/builtin_converters.cpp" typedef bool result_must_be_numeric[result_traits::is_specialized]; --------------------------------------------^ cxx: Info: 1 error detected in the compilation of
This is the same as I got a few days ago. I am pretty sure it was fixed a couple of days ago, but now it is broken again. Any ideas? Cheers, Ralf ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com
Ralf W. Grosse-Kunstleve wrote:
With the latest CVS I am seeing this error again:
[snip]
This is the same as I got a few days ago. I am pretty sure it was fixed a couple of days ago, but now it is broken again. Any ideas?
I would be when it worked in the mean time. Have a look at my reply to your first post in this thread. Unfortunately I'm not sure how to address this problem. Markus
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
Ralf W. Grosse-Kunstleve wrote:
With the latest CVS I am seeing this error again:
[snip]
This is the same as I got a few days ago. I am pretty sure it was fixed a couple of days ago, but now it is broken again. Any ideas?
I would be when it worked in the mean time. Have a look at my reply to your first post in this thread. Unfortunately I'm not sure how to address this problem.
I'm guessing that in strict ansi mode there's no specialization of numeric_limits<unsigned long long>. But the real problem here is that Fernando Cacciola is supposed to fix a looming ODR violation and replace the old numeric_cast with one that's already written and in Boost. http://lists.boost.org/boost/2005/06/28914.php Whassup, Fernando? -- Dave Abrahams Boost Consulting www.boost-consulting.com
I'm guessing that in strict ansi mode there's no specialization of numeric_limits<unsigned long long>. [...]
This is correct. From <limits> : #if defined(__DECCXX) && !(defined(__STD_STRICT_ANSI) || \ defined(__STD_STRICT_ANSI_ERRORS)) && !defined(__DECFIXCXXL634) //++ // Long Long Specialization //-- #if defined(__DECCXX) && !defined(__DECFIXCXXL508) template <> #endif class numeric_limits<long long> { ... Boris ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Cc: "Fernando Cacciola" <fernando_cacciola@hotmail.com> Sent: Thursday, June 23, 2005 10:06 AM Subject: Re: [boost] [tru64cxx] numeric_cast failing again (Boost.Pythoncompilation) Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
Ralf W. Grosse-Kunstleve wrote:
With the latest CVS I am seeing this error again:
[snip]
This is the same as I got a few days ago. I am pretty sure it was fixed a couple of days ago, but now it is broken again. Any ideas?
I would be when it worked in the mean time. Have a look at my reply to your first post in this thread. Unfortunately I'm not sure how to address this problem.
I'm guessing that in strict ansi mode there's no specialization of numeric_limits<unsigned long long>. But the real problem here is that Fernando Cacciola is supposed to fix a looming ODR violation and replace the old numeric_cast with one that's already written and in Boost. http://lists.boost.org/boost/2005/06/28914.php Whassup, Fernando? -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
Ralf W. Grosse-Kunstleve wrote:
With the latest CVS I am seeing this error again:
[snip]
This is the same as I got a few days ago. I am pretty sure it was fixed a couple of days ago, but now it is broken again. Any ideas?
I would be when it worked in the mean time. Have a look at my reply to your first post in this thread. Unfortunately I'm not sure how to address this problem.
I'm guessing that in strict ansi mode there's no specialization of numeric_limits<unsigned long long>. But the real problem here is that Fernando Cacciola is supposed to fix a looming ODR violation and replace the old numeric_cast with one that's already written and in Boost.
http://lists.boost.org/boost/2005/06/28914.php
Whassup, Fernando?
Yea, I'm sorry, since the arrival of the new family menmber (our son) I'm trying to pull back toghether my work life. I'm finishing the fix right now. Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
I'm guessing that in strict ansi mode there's no specialization of numeric_limits<unsigned long long>. But the real problem here is that Fernando Cacciola is supposed to fix a looming ODR violation and replace the old numeric_cast with one that's already written and in Boost.
http://lists.boost.org/boost/2005/06/28914.php
Whassup, Fernando?
Yea, I'm sorry, since the arrival of the new family menmber (our son) I'm trying to pull back toghether my work life.
Congratulations!
I'm finishing the fix right now.
Thank you very much! Do we need to update the docs for numeric_cast or redirect them somehow? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
Markus Schöpflin <markus.schoepflin@comsoft.de> writes:
I'm guessing that in strict ansi mode there's no specialization of numeric_limits<unsigned long long>. But the real problem here is that Fernando Cacciola is supposed to fix a looming ODR violation and replace the old numeric_cast with one that's already written and in Boost.
http://lists.boost.org/boost/2005/06/28914.php
Whassup, Fernando?
Yea, I'm sorry, since the arrival of the new family menmber (our son) I'm trying to pull back toghether my work life.
Congratulations!
Thank you :-)
I'm finishing the fix right now.
Thank you very much! Do we need to update the docs for numeric_cast or redirect them somehow?
OK, I commited the fixes. Here's a list of the changes: (1) Removed the numeric_cast<> code from boost/cast.hpp and added an #include <boost/numeric/conversion/cast.hpp> in its place This change unfortunately means that users of boost/cast.hpp, even for the other casts, are going to get most of the numeric conversion library in; but I don't see any way to automatically "replace" the old numeric_cast<>. (2) Extracted the old numeric_cast<> code into a new file in the numeric conversion library folders. (3) Added a BOOST_WORKAROUND switch into the new boost/numeric/conversion/cast.hpp to redirect the implementation to the old code for those old compilers that can't deal with the new code. (4) Fixed the documentation (on all affected places) (5) Removed the numeric_cast_test.cpp from the conversion jamfile. (6) Temporarily removed all the failure marks on the numeric/conversion library. I need this to determine clearly which compilers need the redirection to the old code and why (the fix could be trivial) After a run of regressions, I'll look at the reports, adjust the redirection macros and put back the failure marks accordingly. IMPORTANT CHANGES: (A) My new numeric_cast<> used as an exception class: bad_numeric_conversion while the old code used bad_numeric_cast Now that the old code is superseeded by the new one, I adopted bad_numeric_cast, which means that if there is any user of the new code relying on it, that code will stop compiling. I have placed a note in the updated documentation, but I suppose I ought to add the note to some release notes as well. Where should I add that? The main index.html? (B) I happen to have bcc5.5.1, which is not on the regressions list but I tested my code with it. It works except for one thing: borland complains about both a template function and a class named "numeric_cast". This is a problem introduced by "boost/mpl/numeric_cast.hpp" which contains a workaround to solve it, but that workaround was not contemplating BCC as a candidate, so I added || BOOST_WORKAROUND(__BORLANDC__,<=0x700) to it. Notice that I tested against the last known BCC version and not just the one I have. Best Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
(B) I happen to have bcc5.5.1, which is not on the regressions list but I tested my code with it. It works except for one thing: borland complains about both a template function and a class named "numeric_cast". This is a problem introduced by "boost/mpl/numeric_cast.hpp" which contains a workaround to solve it, but that workaround was not contemplating BCC as a candidate, so I added
|| BOOST_WORKAROUND(__BORLANDC__,<=0x700)
to it.
Notice that I tested against the last known BCC version and not just the one I have.
The right way to notate that is BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x700)) Otherwise, nice work!! -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
(1) Removed the numeric_cast<> code from boost/cast.hpp and added an #include <boost/numeric/conversion/cast.hpp> in its place
This change unfortunately means that users of boost/cast.hpp, even for the other casts, are going to get most of the numeric conversion library in; but I don't see any way to automatically "replace" the old numeric_cast<>.
But you forgot to check in old_numeric_cast.hpp !! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
(1) Removed the numeric_cast<> code from boost/cast.hpp and added an #include <boost/numeric/conversion/cast.hpp> in its place
This change unfortunately means that users of boost/cast.hpp, even for the other casts, are going to get most of the numeric conversion library in; but I don't see any way to automatically "replace" the old numeric_cast<>.
But you forgot to check in old_numeric_cast.hpp !!
There were myriad other bugs, which I took care of for the bleary-eyed new father. Everything should be okay now, but you might want to check my work over (including in boost/cast.hpp). Oh, and don't forget to use BOOST_TESTED_AT! -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:ur7erlqge.fsf@boost-consulting.com...
David Abrahams <dave@boost-consulting.com> writes:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
(1) Removed the numeric_cast<> code from boost/cast.hpp and added an #include <boost/numeric/conversion/cast.hpp> in its place
This change unfortunately means that users of boost/cast.hpp, even for the other casts, are going to get most of the numeric conversion library in; but I don't see any way to automatically "replace" the old numeric_cast<>.
But you forgot to check in old_numeric_cast.hpp !!
There were myriad other bugs, which I took care of for the bleary-eyed new father. Everything should be okay now, but you might want to check my work over (including in boost/cast.hpp).
Oh, sorry, and thank you for fixing it. I must be getting rust.
Oh, and don't forget to use BOOST_TESTED_AT!
OK Fernando Cacciola SciSoft
--- Fernando Cacciola <fernando_cacciola@hotmail.com> wrote:
IMPORTANT CHANGES:
(A)
My new numeric_cast<> used as an exception class:
bad_numeric_conversion
while the old code used
bad_numeric_cast
Now that the old code is superseeded by the new one, I adopted bad_numeric_cast, which means that if there is any user of the new code relying on it, that code will stop compiling.
Congratulations to the birth of your son! I *really* appreciate that you are still finding the time to do the cleanup work. Boost.Python appears to be in quite good shape, but I am getting this error: % cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DBOOST_DISABLE_THREADS -DNDEBUG -O2 -fast -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4.1_ticker_simple/include/python2.4 -c -o boost/libs/python/src/errors.os /net/legless/scratch1/rwgk/hot/boost/libs/python/src/errors.cpp cxx: Error: /net/legless/scratch1/rwgk/hot/boost/libs/python/src/errors.cpp, line 36: #20 identifier "bad_numeric_cast" is undefined catch(const bad_numeric_cast& x) ----------------^ cxx: Info: 1 error detected in the compilation of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/errors.cpp". It is because bad_numeric_cast is now defined as boost::numeric::bad_numeric_cast instead of boost::bad_numeric_cast. This simple patch fixes the problem: Index: cast.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/cast.hpp,v retrieving revision 1.25 diff -u -r1.25 cast.hpp --- cast.hpp 24 Jun 2005 14:20:41 -0000 1.25 +++ cast.hpp 24 Jun 2005 15:20:12 -0000 @@ -102,4 +102,8 @@ #include <boost/numeric/conversion/cast.hpp> +namespace boost { + typedef boost::numeric::bad_numeric_cast bad_numeric_cast; +} + #endif // BOOST_CAST_HPP OK to commit? Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
OK to commit?
Fixed in CVS with a using-declaration while cleaning up other problems in that area. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> escribió en el mensaje news:20050624152241.93901.qmail@web31505.mail.mud.yahoo.com...
--- Fernando Cacciola <fernando_cacciola@hotmail.com> wrote:
IMPORTANT CHANGES:
(A)
My new numeric_cast<> used as an exception class:
bad_numeric_conversion
while the old code used
bad_numeric_cast
Now that the old code is superseeded by the new one, I adopted bad_numeric_cast, which means that if there is any user of the new code relying on it, that code will stop compiling.
Congratulations to the birth of your son! I *really* appreciate that you are still finding the time to do the cleanup work.
Thank you! It ain't easy with the sister, our 1&1/2-year old daugther, but I'm trying my best.
[SNIPPED] It is because bad_numeric_cast is now defined as boost::numeric::bad_numeric_cast instead of boost::bad_numeric_cast. This simple patch fixes the problem:
Oh, another one of my yesterday's faults. OK, I used the same technique for the exception class coming from old_numeric_cast.hpp Now _the_ exception class is defined solely in numeric/conversion/converter_policies.hpp and put into boost namespace by numeric/conversion/cast.hpp Best Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
[SNIPPED] It is because bad_numeric_cast is now defined as boost::numeric::bad_numeric_cast instead of boost::bad_numeric_cast. This simple patch fixes the problem:
Oh, another one of my yesterday's faults.
OK, I used the same technique for the exception class coming from old_numeric_cast.hpp
Now _the_ exception class is defined solely in
numeric/conversion/converter_policies.hpp
and put into boost namespace by numeric/conversion/cast.hpp
I'm confused. I had already fixed it; and apparently there have been no changes to numeric/conversion/cast.hpp since I made my changes. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> escribió en el mensaje news:uekarikob.fsf@boost-consulting.com...
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
[SNIPPED] It is because bad_numeric_cast is now defined as boost::numeric::bad_numeric_cast instead of boost::bad_numeric_cast. This simple patch fixes the problem:
Oh, another one of my yesterday's faults.
OK, I used the same technique for the exception class coming from old_numeric_cast.hpp
Now _the_ exception class is defined solely in
numeric/conversion/converter_policies.hpp
and put into boost namespace by numeric/conversion/cast.hpp
I'm confused.
I had already fixed it; and apparently there have been no changes to numeric/conversion/cast.hpp since I made my changes.
Right, but boost/numeric/conversion/detail/old_numeric_cast.hpp (which you created becasue I fotgot to commit it) had still its own version of the class, so I just added there an include to "converter_policies.hpp" and added the using just like in cast.hpp Fernando Cacciola SciSoft
I just wanted to say thank you to Fernando and Dave. Boost.Python works again everywhere I've tried (17 different configurations). Cheers, Ralf __________________________________ Discover Yahoo! Use Yahoo! to plan a weekend, have fun online and more. Check it out! http://discover.yahoo.com/
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
Whassup, Fernando?
Yea, I'm sorry, since the arrival of the new family menmber (our son) I'm trying to pull back toghether my work life. I'm finishing the fix right now.
I'm afraid it's caused a regression :( http://tinyurl.com/amm2s (http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/output/...) -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
Whassup, Fernando?
Yea, I'm sorry, since the arrival of the new family menmber (our son) I'm trying to pull back toghether my work life. I'm finishing the fix right now.
I'm afraid it's caused a regression :( http://tinyurl.com/amm2s
Its odd that I'm seeing this so quickly. I *just* (1 minute ago) commited my changes. Anyway, I got to be using the wrong MSCV macro number, casue for <=1600 (VC6) I'm redirecting to the old code. What is the maro value for the compiler that is failing in this case? Fernando Cacciola SciSoft
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
"Fernando Cacciola" <fernando_cacciola@hotmail.com> writes:
David Abrahams wrote:
Whassup, Fernando?
Yea, I'm sorry, since the arrival of the new family menmber (our son) I'm trying to pull back toghether my work life. I'm finishing the fix right now.
I'm afraid it's caused a regression :( http://tinyurl.com/amm2s
Its odd that I'm seeing this so quickly. I *just* (1 minute ago) commited my changes.
Anyway, I got to be using the wrong MSCV macro number, casue for <=1600 (VC6) I'm redirecting to the old code.
VC6 == 1200 vc7 == 1300 vc7.1 == 1310 vc8 == 1400
What is the maro value for the compiler that is failing in this case?
this one is vc6. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Ralf W. Grosse-Kunstleve wrote:
I am not sure this is related, but something bad happened recently. We the CVS from a few minutes ago I get:
% cxx -std strict_ansi -msg_display_number -msg_disable 186,450,1115 -tlocal -DBOOST_DISABLE_THREADS -DNDEBUG -O2 -fast -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/net/legless/scratch1/rwgk/hot/boost -I/usr/local_cci/Python-2.4.1_ticker_simple/include/python2.4 -c -o boost/libs/python/src/converter/builtin_converters.os /net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp cxx: Error: /net/legless/scratch1/rwgk/hot/boost/boost/cast.hpp, line 347: #94 the size of an array must be greater than zero detected during instantiation of "Target boost::numeric_cast<Target,Source>(Source) [with Target=unsigned long long, Source=long]" at line 204 of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/conve rter/builtin_converters.cpp" typedef bool result_must_be_numeric[result_traits::is_specialized]; --------------------------------------------^ cxx: Info: 1 error detected in the compilation of "/net/legless/scratch1/rwgk/hot/boost/libs/python/src/converter/builtin_converters.cpp".
<snip> I'm afraid this has been broken by me with a fix to boost/config/stdlib/roguewave.hpp. When compiling in strict ansi mode, the RW library disables support for long long types. Therefore I added the following lines to the RW config file: ---%<--- // // Disable BOOST_HAS_LONG_LONG when the library has no support for it. // #if !defined(_RWSTD_LONG_LONG) && defined(BOOST_HAS_LONG_LONG) # undef BOOST_HAS_LONG_LONG #endif --->%--- The failure is caused by boost.python not checking BOOST_HAS_LONG_LONG. It uses its own macro magic for this which relies on the value supplied by the python config file. Changing the tests in builtin_converters.cpp to use BOOST_HAS_LONG_LONG instead of HAVE_LONG_LONG makes the file compile for me, but there is a comment regarding this test which indicates that the choice was made deliberately not to use BOOST_HAS_LONG_LONG. I'm not sure on how to properly solve this, any ideas? Markus The compiler itself actually still accepts long long, but it gives a warning for every usage of the type. cxx: Warning: test_long_long.cpp, line 3: the type "long long" is nonstandard unsigned long long u = 0LL; ----------------^ cxx: Warning: test_long_long.cpp, line 3: the type "long long" is nonstandard unsigned long long u = 0LL; -------------------------^ And so on and so on...
participants (6)
-
Boris Gubenko -
David Abrahams -
Fernando Cacciola -
JOAQUIN LOPEZ MU?Z -
Markus Schöpflin -
Ralf W. Grosse-Kunstleve