[assert_no_intrinsic_wchar_t] What the...?
The logic used here seems to be completely and totally broken. Was it even tested? config/compiler/intel.hpp first says: #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else ... #endif So if I have intel6, BOOST_NO_INTRINSIC_WCHAR_T is now set. Then config/compiler/intel.hpp goes on to say: #if defined(BOOST_NO_INTRINSIC_WCHAR_T) #include <cwchar> template< typename T > struct assert_no_intrinsic_wchar_t; template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; }; // if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T: typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_; #else ... #endif So, if I get the error, how exactly am I supposed to "unset BOOST_NO_INTRINSIC_WCHAR_T" before the error occurs? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I want to ask the boost community if there is interest in a decimal floating-point class implementing one or more of the decimal floating-point types that are intended to become part of a future C and C++ standard. This class would be a wrapper class around Mike Cowlishaws decNumber C library. You can take a look at my first preliminary version (it is just a first try, the design is far from perfect, it is incomplete, its notation is inconsistent and not according to boost conventions) at http://www.rkaiser.de/rkaiser/DecFPClass/DecFPClass.html Most of its operators work as they should do, and most of Mikes testcases pass successfully. The function DecimalFloat_Testcases("d:\\cpp.boo\\decnumber\\decnumberclass\\decTest\\") in my test program test_rk reads all the testcases from Mikes decTest files and logs each testcase in a file (bcb files were created with Borland C++Builder 6, gcc with MinGW g++, and msc with MS Visual Studio .Net). With “grep "###number" *.log” you get the summary lines: File abs.decTest_bcb.log: ###number of tests passed=87 failed=2 File abs.decTest_gcc.log: ###number of tests passed=87 failed=2 File abs.decTest_msc.log: ###number of tests passed=87 failed=2 File add.decTest_bcb.log: ###number of tests passed=773 failed=45 File add.decTest_gcc.log: ###number of tests passed=773 failed=46 File add.decTest_msc.log: ###number of tests passed=773 failed=45 ... If the boost community is interested, if I find enough time, and if everything works as intended, the resulting classes would be a reference implementation for the new standard decimal floating point types, or at least a close one. Richard Kaiser
On Sun, 16 May 2004 19:26:51 +0200, Richard Kaiser wrote
I want to ask the boost community if there is interest in a decimal floating-point class implementing one or more of the decimal floating-point types that are intended to become part of a future C and C++ standard.
At this moment I don't need this, but I've need something like this in the past and suspect I will again. So I'd like to see it. Only question is will the compiler vendors get there first if it's already clear this is going in the standard? Jeff
"David Abrahams" <dave@boost-consulting.com> wrote:
The logic used here seems to be completely and totally broken. Was it even tested?
config/compiler/intel.hpp first says:
#if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else ... #endif
So if I have intel6, BOOST_NO_INTRINSIC_WCHAR_T is now set. Then config/compiler/intel.hpp goes on to say:
#if defined(BOOST_NO_INTRINSIC_WCHAR_T) #include <cwchar> template< typename T > struct assert_no_intrinsic_wchar_t; template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; }; // if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T: typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_; #else ... #endif
Seems it should be #if !(defined BOOST_NO_INTRINSIC_WCHAR_T) ... The checking code is new (not shipped in 1.31.0). /Pavel
"Pavel Vozenilek" <pavel_vozenilek@hotmail.com> writes:
So if I have intel6, BOOST_NO_INTRINSIC_WCHAR_T is now set. Then config/compiler/intel.hpp goes on to say:
#if defined(BOOST_NO_INTRINSIC_WCHAR_T) #include <cwchar> template< typename T > struct assert_no_intrinsic_wchar_t; template<> struct assert_no_intrinsic_wchar_t<wchar_t> { typedef void type; }; // if you see an error here then you need to unset BOOST_NO_INTRINSIC_WCHAR_T: typedef assert_no_intrinsic_wchar_t<unsigned short>::type assert_no_intrinsic_wchar_t_; #else ... #endif
Seems it should be
#if !(defined BOOST_NO_INTRINSIC_WCHAR_T) ...
No, clearly not. The code above checks that wchar_t == unsigned short, and causes an error otherwise. That corresponds to not having an intrinsic wchar_t. Anyway, if you changed the condition and the assertion fired in the other branch of the #if, we'd have the same problem.
The checking code is new (not shipped in 1.31.0).
I know that, and I don't mean to sound harsh, but really that's no excuse. Before stuff like this is checked in, it needs to be tested, since it affects all boost developers using that compiler. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
No, clearly not. The code above checks that wchar_t == unsigned short, and causes an error otherwise. That corresponds to not having an intrinsic wchar_t. Anyway, if you changed the condition and the assertion fired in the other branch of the #if, we'd have the same problem.
The checking code is new (not shipped in 1.31.0).
I know that, and I don't mean to sound harsh, but really that's no excuse. Before stuff like this is checked in, it needs to be tested, since it affects all boost developers using that compiler.
It *was* tested with Intel 7 and Intel 8, and does exactly what it's supposed to do with those compilers. Intel 6 wasn't tested because I don't have access to that compiler - it's not even supported by Intel any more is it? BTW the offending code: #if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else Has been in cvs for a long time, it was checked in with: Revision 1.23 - (download), view (text) (markup) (annotate) - [select for diffs] Sun Jun 1 18:06:27 2003 UTC (11 months, 2 weeks ago) by beman_dawes Changes since 1.22: +1 -1 lines Diff to previous 1.22 BOOST_NO_INTRINSIC_WCHAR_T now correct for 7.0 on Win32, based on config_info report The only difference is that the code now checks to verify that it is correct - in other words we're detecting an error that previously went unnoticed unless you tried including type_traits/*.hpp or something. John.
John Maddock wrote:
The only difference is that the code now checks to verify that it is correct - in other words we're detecting an error that previously went unnoticed unless you tried including type_traits/*.hpp or something.
Probably the code needs a comment along these lines to explain what it is trying to do. -- Giovanni Bajo
The only difference is that the code now checks to verify that it is correct - in other words we're detecting an error that previously went unnoticed unless you tried including type_traits/*.hpp or something.
Probably the code needs a comment along these lines to explain what it is trying to do.
Will do, I'll try and see if I can wangle a copy of Intel 6 as well. John.
"John Maddock" <john@johnmaddock.co.uk> writes:
I know that, and I don't mean to sound harsh, but really that's no excuse. Before stuff like this is checked in, it needs to be tested, since it affects all boost developers using that compiler.
It *was* tested with Intel 7 and Intel 8, and does exactly what it's supposed to do with those compilers. Intel 6 wasn't tested because I don't have access to that compiler
Understood.
- it's not even supported by Intel any more is it?
Not sure why that matters. People still use it.
BTW the offending code:
#if BOOST_INTEL_CXX_VERSION < 700 # define BOOST_NO_INTRINSIC_WCHAR_T #else
Has been in cvs for a long time, it was checked in with:
Revision 1.23 - (download), view (text) (markup) (annotate) - [select for diffs] Sun Jun 1 18:06:27 2003 UTC (11 months, 2 weeks ago) by beman_dawes Changes since 1.22: +1 -1 lines Diff to previous 1.22 BOOST_NO_INTRINSIC_WCHAR_T now correct for 7.0 on Win32, based on config_info report
The only difference is that the code now checks to verify that it is correct - in other words we're detecting an error that previously went unnoticed unless you tried including type_traits/*.hpp or something.
I don't think even that would've detected the issue, since before this I was using my Intel6 toolset smoothly with all kinds of Boost code, especially type traits. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
I don't think even that would've detected the issue, since before this I was using my Intel6 toolset smoothly with all kinds of Boost code, especially type traits.
OK, understood, I have a copy of Intel 6 to test with now, and the code should now be functioning correctly with that version as well. Enjoy, John.
"John Maddock" <john@johnmaddock.co.uk> writes:
I don't think even that would've detected the issue, since before this I was using my Intel6 toolset smoothly with all kinds of Boost code, especially type traits.
OK, understood, I have a copy of Intel 6 to test with now, and the code should now be functioning correctly with that version as well.
Enjoy,
Thanks, John! -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
participants (6)
-
David Abrahams -
Giovanni Bajo -
Jeff Garland -
John Maddock -
Pavel Vozenilek -
Richard Kaiser