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