Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-05-27 04:14:28


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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk