This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Switch question
- To: Benjamin Kosnik <bkoz at redhat dot com>
- Subject: Re: Switch question
- From: Gabriel Dos Reis <gdr at codesourcery dot com>
- Date: 24 May 2001 10:52:04 +0200
- Cc: gcc at gcc dot gnu dot org, Ryszard dot Kabatek at softax dot pl, mark at codesourcery dot com, jason at redhat dot com
- Organization: CodeSourcery, LLC
- References: <200105232139.f4NLdNN01979@fillmore.constant.com>
Benjamin Kosnik <bkoz@redhat.com> writes:
| Ryszard, I can reproduce this too. It looks like a compiler bug.
No, this is not a compiler bug. It is a libary bug. Here is why:
>From include/bits/ios_base.h
enum _Ios_Openmode { _M_ios_openmode_end = 1L << 16 };
inline _Ios_Openmode
operator&(_Ios_Openmode __a, _Ios_Openmode __b)
{ return _Ios_Openmode(static_cast<int>(__a) &
static_cast<int>(__b)); }
inline _Ios_Openmode
operator|(_Ios_Openmode __a, _Ios_Openmode __b)
{ return _Ios_Openmode(static_cast<int>(__a) |
static_cast<int>(__b)); }
[...]
I've always wondered if that was a good thing to do. Is that
complication really needed? There is the following comment in that
header:
// The following definitions of bitmask types are enums, not ints,
// as permitted (but not required) in the standard, in order to provide
// better type safety in iostream calls. A side effect is that
// expressions involving them are no longer compile-time constants.
Actually, even though the definitions are permitted, the overloads are
not.
Comments?
-- Gaby
CodeSourcery, LLC http://www.codesourcery.com