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

[Michael Matz <matz at suse dot de>]

Hi,

On Sat, 28 Aug 2004, Andreas Schwab wrote:

> > 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.
> 
> Do you think that assignments from non-enum to enum are frequent
> operations in C++?

How frequent do you think they must be to deserve an implementation which
doesn't unnecessarily cripple performance?  And how should we measure this
frequency?  I can offer one case where such casts are usually used off the
top of my head, which is when enums have to be serialized (to disk, to
net, to socket for IPC, and similar stuff).  You usually read, say 4 bytes
in network order, and try to make a enum out of this.

If the performance degradation in this case is really noticable might be
under discussion but I think the C++ standard should allow a performant
solution by default, without requiring hacks like:

enum { a, b, other_fields ..., BIG_ENOUGH_TO_WIDEN_THE_ENUM=0xffffffff }

> I don't think so.  The explicit cast also suggests that the conversion
> may not be a nop.

IMHO it suggests type safety.  I'm against the notion that any syntactic
structure already implicitely suggests a certain behaviour, in this case
non-nopiness ;)  It is the case for some such structures, but this should
not be used as excuse for allowing also other constructs to be non-nops,
when a performance neutral implementation is possible and feasible without
any adverse effect on the language (as can be seen by every compiler
implementing it thus in this case).


Ciao,
Michael.