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]
Other format: [Raw text]

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


Hi,

On Fri, 27 Aug 2004, Gabriel Dos Reis wrote:

> | So
> | 
> | e = (E)7;
> | 
> | printf ("%d\n", (int)e));
> | 
> | should print 3, and not 7 as is does now, and this should work by
> | converting integer types into enumeration types, and not by masking
> | upon converting enumeration types to ints?  Did I get that right?
> 
> Yes, the masking happens when converting from integer to enumeration,
> not from enumeration to integer.

In this case I think the C++ standard should be changed in a way to not 
require a masking operation for each and every assignment from an integer 
of which the range is unknown.  Yes this masking happens only for such 
casts, and not for every operation if the operands are enums already, but 
it still will hurt performance in the real world.

Additionally, the fact that every compiler in the world does _not_ do this 
masking and that standards should standardize existing practice strongly 
indicates that changing (I'm tempted to say correcting) the standard is 
the way to go.

I believe such correction would require some deeper changes on what can be
expected of an enum variable (in particular it wouldn't be ensured anymore
that enum values really are in the range of the bitfield, but instead in
the range of the underlying integer type, i.e. similar to C).  I
understand that we can't use real bitfields anymore to implement enums,
but we don't loose anything by this, especially given that we don't do it
right now (and I'm not even sure, if it would be allowed, that for
instance an "enum {zero,one}" only has one bit storage, e.g. if combined
with real bitfields in a struct).

The other type strictness rules can be retained, so from a type safety
p.o.v.  this doesn't need to change anything.  But IMHO this requirement
of having the value be masked most of the time is very suboptimal.  I
can't think of any reason why the writers of the standard would intend
this behaviour, so I would assume an oversight when writing the standard
itself.


Ciao,
Michael.


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