( Currently the regression status pages for IBM and SGI are not updated for two weeks because I'm unable to even compile the regression test tools. And more and more libraries are braking (on vacpp) so here's another shot at getting them to run again. ) In boost/test/detail/basic_cstring/basic_cstring.hpp contains following line: "enum npos_type { npos = (size_type)-1 }" Now size_type is previously defined as a size_t. The IBM is a 64 bit machine and size_t is 64 bits wide whereas an int is 32 bits wide. Therefore VisualAge does not accept this line. Would soth break if we change this to "enum npos_type { npose = -1 }"
Toon Knapen wrote:
"enum npos_type { npose = -1 }"
(I assume 'npose' is a typo for 'npos') I'm unsure whether this would be the right thing to do here. If you define npos like above, it will result in a 32 bit value. When used together with 64 bit values (size_t), this is IMHO a potential source of bugs - although I don't have evidence. Have you considered/tried static const size_t npos = -1; or optionally (if npos_type is needed): typedef size_t npos_type; static const npos_type npos = -1; ? This should (AFAICS) provide the "correct" 64 bit value you are looking for. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
Daniel Frey ha escrito:
Toon Knapen wrote:
"enum npos_type { npose = -1 }"
A remark here. AFAICS, if vcapp fails in enum npos_type { npos = (size_type)-1 } the way Toon explained, it is the compiler's fault, since an enum must be large enough to accommodate any integral constant. If I'm not wrong, the compiler should make the underlying type of npos_type at least 64 bit. This does not help much, since the real problem is to make this work for as many compilers as possible, not to discern whose fault it is.
(I assume 'npose' is a typo for 'npos')
I'm unsure whether this would be the right thing to do here. If you define npos like above, it will result in a 32 bit value. When used together with 64 bit values (size_t), this is IMHO a potential source of bugs - although I don't have evidence.
Have you considered/tried
static const size_t npos = -1;
This is not supported for every compiler (and Boost.Test should seek for maximum coverage), as reported by the Boost.Config defect macro BOOST_NO_INCLASS_MEMBER_INITIALIZATION. Maybe the following is a good compromise #if defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) enum npos_type { npos = (size_type)-1 } #else static const size_t npos = (size_type)-1; #end This would work for any compiler except those compilers for which * there are problems with enums that should be greater than an unsigned int, AND * BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined. Alas, after checking boost/config/compiler/vacpp.hpp, seems like vacpp<600 would also fail with this workaround, but at least vacpp==600 (and any other compiler) should work. Comments? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
On Thu, May 27, 2004 at 11:14:28AM +0200, Joaqu?n M? L?pez Mu?oz wrote:
Daniel Frey ha escrito:
Toon Knapen wrote:
"enum npos_type { npose = -1 }"
A remark here. AFAICS, if vcapp fails in
enum npos_type { npos = (size_type)-1 }
the way Toon explained, it is the compiler's fault, since an enum must be large enough to accommodate any integral constant. If I'm not wrong, the compiler should make the underlying type of npos_type at least 64 bit.
Yes, the compiler should use a larger type than int for the enum. Can it be persuaded to do so? Maybe it ignores the cast to size_type and uses an int because -1 will fit in an int, in which case maybe this would make it use a bigger type: enum npos_type { npos = -1UL } Just a thought. I've never used vacpp let alone tested this code with it, jon -- "It is useless to attempt to reason a man out of a thing he was never reasoned into." - Jonathan Swift
From: Toon Knapen <toon.knapen@fft.be>
Jonathan Wakely wrote:
Can it be persuaded to do so? Maybe it ignores the cast to size_type and uses an int because -1 will fit in an int, in which case maybe this would make it use a bigger type:
enum npos_type { npos = -1UL }
nope, does not work.
I'm not surprised. The original code cast -1 to size_type, an unsigned type. The above makes npos a negative integral value which probably doesn't always interact correctly elsewhere. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Joaquín Mª López Muñoz wrote:
Maybe the following is a good compromise
#if defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) enum npos_type { npos = (size_type)-1 } #else static const size_t npos = (size_type)-1; #end
Well currently BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined for the latest version of vacpp (version 6) too so I would suggest just for the time being do #if defined(__IBMCPP__) // VisualAge compiler can't handle 64 bit enums static const size_t npos = -1 ; #else enum npos_type { npos = (size_type)-1 } ; #endif This will make it work on VisualAge too. Agreed ?
Toon Knapen ha escrito:
Joaquín Mª López Muñoz wrote:
Maybe the following is a good compromise
#if defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) enum npos_type { npos = (size_type)-1 } #else static const size_t npos = (size_type)-1; #end
Well currently BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined for the latest version of vacpp (version 6) too so I would suggest just for the time being do
#if defined(__IBMCPP__) // VisualAge compiler can't handle 64 bit enums static const size_t npos = -1 ; #else enum npos_type { npos = (size_type)-1 } ; #endif
How come this works if BOOST_NO_INCLASS_MEMBER_INITIALIZATION tells us otherwise? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
#if defined(__IBMCPP__) // VisualAge compiler can't handle 64 bit enums static const size_t npos = -1 ; #else enum npos_type { npos = (size_type)-1 } ; #endif
How come this works if BOOST_NO_INCLASS_MEMBER_INITIALIZATION tells us otherwise?
Good question. I should have explained of course. Well vacpp has only in some circurmstances a problem with the in class member initialization. For instance following does not work (confirmed by IBM): class A { public: static const int value = true ; } ; int main() { int v1 = A::value ; // does work bool v2 = A::value ; // does not work return 0 ; } ;
Joaquín Mª López Muñoz wrote: . . . Good question. I should have explained of course. Well vacpp has only in some circurmstances a problem with the in class member initialization. For instance following does not work (confirmed by IBM):
class A { public: static const int value = true ; } ;
int main() { int v1 = A::value ; // does work bool v2 = A::value ; // does not work return 0 ; } ;
Hello, I know i argue with eminent C++ specialists in this group, but i think the code above is not correct. To my best knowledge even with the inclass line static const int value = true ; you have to give a definition outside of the class: int A::value; Apart from that return 0; should be unnecessary and there is a spurious semicolon after the last brace; Greetings Franz
On Thu, May 27, 2004 at 04:06:19PM +0200, Dr. Franz Fehringer wrote:
Joaqu?n M? L?pez Mu?oz wrote: . . . Good question. I should have explained of course. Well vacpp has only in some circurmstances a problem with the in class member initialization. For instance following does not work (confirmed by IBM):
class A { public: static const int value = true ; } ;
int main() { int v1 = A::value ; // does work bool v2 = A::value ; // does not work return 0 ; } ;
Hello,
I know i argue with eminent C++ specialists in this group, but i think the code above is not correct. To my best knowledge even with the inclass line static const int value = true ; you have to give a definition outside of the class: int A::value;
Only if A::value is "used in the program". Stroustrup says if you use it in a way that requires the object to be stored in memory, e.g take its address AFAICT you don't need to give an out-of-class definition if the value is only used in integral constant expressions. Is that right?
Apart from that return 0; should be unnecessary
But it isn't incorrect. jon -- Emacs is a nice OS - but it lacks a good text editor. That's why I am using Vim. - Anonymous
Jonathan Wakely wrote:
To my best knowledge even with the inclass line static const int value = true ; you have to give a definition outside of the class: int A::value;
Only if A::value is "used in the program". Stroustrup says if you use it in a way that requires the object to be stored in memory, e.g take its address
AFAICT you don't need to give an out-of-class definition if the value is only used in integral constant expressions. Is that right?
Not quite. In practice, you are right, but the standard requires *exactly* one definition for all static data members. See 9.4.2/5. So, while Franz is right in theory, you are right in practice. :) And FWIW it's IMHO irrelevant here anyway as we are trying to create a workaround for a compiler bug. The generic (and presumably correct) code is not touched, we just add a #ifdef'ed something which simply works - whether or not it's standard conformant. And I think we've already seen worse bugs and workarounds already :-D Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
Daniel Frey <daniel.frey@aixigo.de> writes:
Jonathan Wakely wrote:
To my best knowledge even with the inclass line static const int value = true ; you have to give a definition outside of the class: int A::value; Only if A::value is "used in the program". Stroustrup says if you use it in a way that requires the object to be stored in memory, e.g take its address AFAICT you don't need to give an out-of-class definition if the value is only used in integral constant expressions. Is that right?
Not quite. In practice, you are right, but the standard requires *exactly* one definition for all static data members. See 9.4.2/5. So, while Franz is right in theory, you are right in practice. :)
Actually you're all wrong. Or right. There's a Core DR on this one. The vacpp behavior will become nonconforming when that DR is official. It may already be so; I'm not sure if it went into TC1 or not. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com
On 5/27/04 5:14 AM, "Joaquín Mª López Muñoz" <joaquin@tid.es> wrote: [SNIP]
Maybe the following is a good compromise
#if defined(BOOST_NO_INCLASS_MEMBER_INITIALIZATION) enum npos_type { npos = (size_type)-1 } #else static const size_t npos = (size_type)-1; #end
Doesn't the BOOST_STATIC_CONSTANT macro cover this?
This would work for any compiler except those compilers for which
* there are problems with enums that should be greater than an unsigned int, AND * BOOST_NO_INCLASS_MEMBER_INITIALIZATION is defined. [TRUNCATE]
-- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
participants (8)
-
Daniel Frey -
Daryle Walker -
David Abrahams -
fehrin＠t-online.de -
Joaquín Mª López Muñoz -
Jonathan Wakely -
Rob Stewart -
Toon Knapen