Re: [boost] [Boost-users] numeric_cast_traits/cstdint: request for fix in boost1.49
Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was being interpreted as a char, This causes duplicate class definition in the file ./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp and hence many of compiled boost libs fail.
Thanks for raising this on the list, I just posted these comments to the Trac ticket: "IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc. IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout. BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux. Reassigning to the person who made these changes..." Not sure if we can fix this for 1.49, but you're right, it is a high priority. Hopefully Brandon Kohn is reading this as he made those changes? John.
On Sat, Jan 28, 2012 at 8:09 AM, John Maddock <boost.regex@virgin.net> wrote:
Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was being interpreted as a char, This causes duplicate class definition in the file ./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp and hence many of compiled boost libs fail.
Thanks for raising this on the list, I just posted these comments to the Trac ticket:
"IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc.
IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout.
BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux.
Reassigning to the person who made these changes..."
Not sure if we can fix this for 1.49, but you're right, it is a high priority.
Thanks, John. There should be time to fix this for 1.49, but it will help if you can shepherd this along. --Beman
John Maddock wrote:
Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was being interpreted as a char, This causes duplicate class definition in the file ./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp and hence many of compiled boost libs fail.
Thanks for raising this on the list, I just posted these comments to the Trac ticket:
"IMO this is the wrong fix: our code should make no assumptions about the actual type of uintXX_t etc.
IMO the preprocessed headers are just plain wrong - you can't mix concrete types (char short etc) with typedefs (intXX_t) because you're just asking for problems with duplicate specializations. It has to be all real types throughout.
BTW in addition to the two platforms mentioned above, this is also broken for Sun on Linux.
Reassigning to the person who made these changes..."
Not sure if we can fix this for 1.49, but you're right, it is a high priority.
Hopefully Brandon Kohn is reading this as he made those changes?
I've taken a careful look at this library as part of something else I'm working on. Its really hard to understand how the library is supposed to be used and what facilities it provides. The usage of policies makes it clear that one can customize it, but the default policies don't seem to be explained. For example, I had a simple question: if I use the library with the default policies to convert an unsigned char with a value of 128 to a signed char, what will happen? Will an exception be thrown (which is what I want) or will something else happen. I couldn't get an easy answer to a question like this. Of course I could troll the source, but that's also quite time consuming. For starters, the documenation needs to be improved. Robert Ramey
On 1/28/2012 12:38 PM, Robert Ramey wrote:
I've taken a careful look at this library as part of something else I'm working on. Its really hard to understand how the library is supposed to be used and what facilities it provides. The usage of policies makes it clear that one can customize it, but the default policies don't seem to be explained.
I added some documentation for the way to customize policies, but didn't get the new docs properly into the 1.48 release branch on time for the release. The new docs are in the release trunk. There is an example that shows how to override the default policies for a custom numeric type using the numeric_cast_traits specialization. For example, I had a simple question:
if I use the library with the default policies to convert an unsigned char with a value of 128 to a signed char, what will happen? Will an exception be thrown (which is what I want) or will something else happen.
I believe the default behavior for the range checker is to see if the new type's range as defined in numeric_limits<new type> can represent the number. If the number falls out of that range the overflow handler will fire. There the default behavior is to throw an overflow exception (positive or negative).
Brandon
Hello, I've put a fix for this up on the trunk. I've run my unit tests on vc100 and gcc-4.5.3 cygwin. Could some of you with the other platforms give it a try? Cheers, Brandon
I've put a fix for this up on the trunk. I've run my unit tests on vc100 and gcc-4.5.3 cygwin. Could some of you with the other platforms give it a try?
Confirmed that existing tests fail with old code (including with VC8). Tested with new code and VC8,9,10 and Intel-11.1, 12.1 all OK. On Linux gcc-4.4, 4.6 intel-11.1, 12.1 and clang all OK. Sun on Linux still fails, but appears to be a lexical_cast issue and not your problem - will report that separately. HTH, John.
John Maddock wrote:
Sun on Linux still fails, but appears to be a lexical_cast issue and not your problem - will report that separately.
Antony Polukhin is the current maintainer of lexical_cast. So it would be better to change "owner" from nasonov to apolukhin in the ticket #6462. (This kind of changes is allowed only to authenticated users, so I cannot do this.) Regards, Michel
John Maddock wrote:
Sun on Linux still fails, but appears to be a lexical_cast issue and not your problem - will report that separately.
Antony Polukhin is the current maintainer of lexical_cast. So it would be better to change "owner" from nasonov to apolukhin in the ticket #6462. (This kind of changes is allowed only to authenticated users, so I cannot do this.)
Oops, fixed that one, plus a couple other recent lexical_cast tickets, and changed the default for that component so this doesn't happen again.... John.
Shall I push the fixes to the release? Cheers, Brandon
participants (5)
-
Beman Dawes -
Brandon Kohn -
John Maddock -
Michel Morin -
Robert Ramey