Help with bit-field semantics in C and C++

Gabriel Dos Reis gdr@integrable-solutions.net
Wed Aug 25 00:57:00 GMT 2004


Joe Buck <Joe.Buck@synopsys.COM> writes:

| On Wed, Aug 25, 2004 at 02:21:40AM +0200, Gabriel Dos Reis wrote:
| > |  Is that a bug we must fix?
| > 
| > Yes, in as much as we're not allowed to crash.  The fix consists
| > in projecting the value to the proper range -- this need doing only
| > when the source value manifestly comes from non enum-value preserving
| > operations or unknown sources.
| 
| Then we're screwed; C++ is doomed to be slower than C for a large number
| of programs that I write, and all implementations are broken.
| 
| That is, I know of no compiler that, given
| 
| enum E { zero, one, two, three };
| 
| E foo;
| 
| void init_foo(int arg) {
|      foo = (E)arg;
| }
| 
| generates any kind of checking or masking to assure that foo does not
| get an out-of-range value.

Proper enum operations are fast for C++ enums. Only type-puning
operations get slow down, but C++ has taken effort to discourage those
through type rules -- which is one of the area where deliberate
decisions have been made to depart from C.

Did you notice that

     enum E {
        zero, one, two, three
     };

     int main(void)
     {
        enum E e = zero;
        ++e;
     }

is valid C, but invalid C++?  The root reasons are the same here.

-- Gaby



More information about the Gcc mailing list