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