This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Switch question


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]