Re: Switch question

[Ryszard Kabatek <Ryszard dot Kabatek at softax dot pl>]

Gabriel Dos Reis wrote:
> 
> 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?


I hope it will be fixed in the gcc-3.0 release.
In other case one will have to write something like that:

#include <iostream>
 
int f(std::ios_base::openmode mode)
{
  switch(mode & ~std::ios_base::ate) {
    case static_cast<int>(std::ios_base::out) |
         static_cast<int>(std::ios_base::trunc):
        return 1;
  }
  return 0;
}

Regards
-- 
Ryszard Kabatek