kc@rna.UUCP (Kaare Christian) (01/08/90)
Hey there language lawyer types...
I ran across the following while using Zortech C++ 2. The behavior
seems wrong to me, but I couldn't decide from the ugly reddish
manual what was the correct behavior.
In the following example, my intent is to declare a constant enum by or'ing
together some enum constants. What I discovered with ZTC is that I can
only do this if I cast each of the enum values to const. Since enum values
are already constants (but not "const", it seems), this seems burdensome.
Is this a Zortechism, or is this standard C++ behavior?
enum bits { zero = 1, one = 2, two = 4 };
bits ZeroAndOne = zero | one; // OK
const bits OneAndTwo = one | two; // Fails with ztc2.01
// complaint is type mistmatch, had <enum bits> and <const enum bits>
const bits OneAndTwoAgain = (const bits)one | (const bits)two; // OK
// but casts on the right look very redundantcomeau@utoday.UUCP (Greg Comeau) (01/09/90)
In article <963@rna.UUCP> kc@rna.UUCP (Kaare Christian) writes: >Is this a Zortechism, or is this standard C++ behavior? >enum bits { zero = 1, one = 2, two = 4 }; >bits ZeroAndOne = zero | one; // OK >const bits OneAndTwo = one | two; // Fails with ztc2.01 > // complaint is type mistmatch, had <enum bits> and <const enum bits> >const bits OneAndTwoAgain = (const bits)one | (const bits)two; // OK > // but casts on the right look very redundant Actually what we have here for each case it a type mismatch since the only valid 'bits' are 'zero', 'one', and 'two'. A common extension in C and C++ is to let the assignment happen regardless (with a warning, not an error) because there is an enum/int conversion often present even if the given int is not a value enum "option" (value?). As to "<enum bits> and <const enum bits>", I'd say that is even worse than superfluous and is wrong since the | results in a respective promotion/ conversion producing an int which is similar to having said 'bits xyz = 5;' whether const or not. Actually, I'm a bit bewildered that the last case works since the result cannot be a 'bits' even if the bit pattern was ok, no less making each operand a const to make it work (although I think I see what it was doing). -- Greg, Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Also, mag writer for UNIX Today! (SysAdm columnist), Microsoft Systems Journal (C programming), + others. Also, BIX c.language & c.plus.plus conf. moderator. Here:attmail!csanta!greg / BIX:comeau / CIS:72331, 3421 / voice:718-849-2355
jimad@microsoft.UUCP (JAMES ADCOCK) (01/10/90)
cfront 2.0 accepts this with the appropriate warning that you're assigning
an int to an enum -- when you or individual bits together you end up with
values not in the set original defined in the bits enum -- so how can the
receiver of the or results be a "bits" ?
The following slight change makes more sense to me, and compiles under cfront
2.0 without warning:
enum bit { .... };
typedef int bits;
...
bits someresult = one | two | whatever;
[not to imply bit or bits are good names to use for these things, nor
zero, one, two, ...]
Another approach to setting individual bits is to use one or the other
Bit, bits, or Bitset classes floating around. The typical trick is to
identify individual bits by their shift number, then automagically shift
1 << shiftnum inline using constructors, inline operators, or whatever,
to allow a small set of these values to be packed in an int. Since most
compilers eval say 1 << 3 to be 8 at compile time, these classes are close
to the efficiency offered by the more historical enum approaches.jss@jra.ardent.com (01/10/90)
In article <10197@microsoft.UUCP> jimad@microsoft.UUCP (JAMES ADCOCK) writes: > >cfront 2.0 accepts this with the appropriate warning that you're assigning >an int to an enum -- when you or individual bits together you end up with >values not in the set original defined in the bits enum -- so how can the >receiver of the or results be a "bits" ? > The question of what an enum type "really is", has bedeveled the concept ever since it was introduced into C. Over the years a lot has been said, but I believe a consensus finally emerged and both ANSI C and the most recent C++ reference manual agree that they are integral types. This means that its perfectly sensible to assign arbitrary integer values to variables of enum type. Jerry Schwarz
williams@umaxc.weeg.uiowa.edu (Kent Williams) (01/10/90)
I just received what was recently referred to as the "Ugly Reddish
Book" from AT&T (i.e. AT&T C++ Product Reference) That sounds like a
nickname that should stick!
Incidentally, they sent me the wrong book (release notes instead of
selected readings), and I called them up. The woman apologized
profusely and is sending the proper book federal express.
The funny thing was she didn't want me to mail the wrong book back
because it 'wasn't worth it.' This is great! If they send it to me,
it costs me 20$, but they don't want me to send it back because it's
not worth it. I think I've discovered some sort of economic diode!
--
Kent Williams "What's an Address Bus? How do Icons work?"
williams@umaxc.weeg.uiowa.edu -- Advertisement for Time-Life Books kc@rna.UUCP (Kaare Christian) (01/10/90)
Regarding my const enums query, I originally ran into the problem while programming an AM9513 counter timer chip. It has several registers, and I wanted to make sure that I only stuffed the appropriate bit patterns into each register. C++ 2.0's stronger enum typing (no automatic conversion of int to enum) made it possible for me to create safe set of subroutines for programming the chip. For example, I made a MasterMode enum type containing all the bit fields of the am9513 master mode register, and I made a WriteMasterMode function that only accepted a MasterMode argument. That all worked great. The only hitch is that, to create a value for, say, the master mode register, I had to OR together several of the MasterMode enum constants. I was aware that ORing enums together was likely to trigger an automatic conversion to int, and possibly a warning when that was converted back to the original enum type. What I found surprising was that I couldn't get this to work when const entered the picture. My motivation for const was to continue to have the type safety while avoiding the penalty of consuming a storage location for each of my predefined bitpatterns. Isn't that one of the main reasons for const global data types? In article <10197@microsoft.UUCP>, jimad@microsoft.UUCP (JAMES ADCOCK) writes: > > The following slight change makes more sense to me, and compiles under cfront > 2.0 without warning: > > enum bit { .... }; > > typedef int bits; > > ... > > bits someresult = one | two | whatever; > I'm aware of the technique, but it doesn't let me use type checking to avoid putting a countermode value into a mastermode register. > [not to imply bit or bits are good names to use for these things, nor > zero, one, two, ...] Yup, bad names in general, it was just the smallest example I could devise. I guess that a better solution than what I showed before is the following: bits x = (bits)(one | two); const bits y = (const bits)(one | two); This coerces the expr result back to what I want, and looks more reasonable. But in general, the 2.0 tightening of the enum type rules seems not tight enough. Arithmetic operations on enums promote to int, thereby losing the typing. Why not have arithmetic operations on enums *act* as int operations, but retain typing? One could only do binop stuff on enums of the same type (unless explicit casts were used), and enum op enum would always produce an enum type. In hindsight, I think I should have used a classier solution (pun intended) or bitfields. Kaare Christian
comeau@utoday.UUCP (Greg Comeau) (01/11/90)
In article <9925@ardent.UUCP> jss@jra.ardent.com () writes: >In article <10197@microsoft.UUCP> jimad@microsoft.UUCP (JAMES ADCOCK) writes: >>cfront 2.0 accepts this with the appropriate warning that you're assigning >>an int to an enum -- when you or individual bits together you end up with >>values not in the set original defined in the bits enum -- so how can the > >The question of what an enum type "really is", ...a consensus finally >emerged and both ANSI C and the most recent C++ reference manual agree >that they are integral types. This means that its perfectly sensible to >assign arbitrary integer values to variables of enum type. > >Jerry Schwarz Although I agree that enum's are now integral types in both dpANSI C and C++ one must take the semantics of enums into consideration before saying that they (integrals) are completely convertable amongst each other. First although enums contain integer constant values (int's actually), they are not an integer types (a basic type accto ANSI) per se. Also, although ANSI C makes no mandation as I recall, in C++ enums are actually types and therefore although the enumerators values are convertable to int values, only enumerator values are supposed to be assigned to objects of the respective enumeration (in other words these is no implicit integral promotion or conversion when going into an enum lvalue). -- Greg, Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Also, mag writer for UNIX Today! (SysAdm columnist), Microsoft Systems Journal (C programming), + others. Also, BIX c.language & c.plus.plus conf. moderator. Here:attmail!csanta!greg / BIX:comeau / CIS:72331, 3421 / voice:718-849-2355
jimad@microsoft.UUCP (JAMES ADCOCK) (01/11/90)
>The question of what an enum type "really is", has bedeveled >the concept ever since it was introduced into C. Over the >years a lot has been said, but I believe a consensus finally >emerged and both ANSI C and the most recent C++ reference manual agree >that they are integral types. > >This means that its perfectly sensible to assign arbitrary integer >values to variables of enum type. > >Jerry Schwarz I would claim on the contrary that the decision by both ANSI-C and C++ to consider enums integral types is a pragmatic decision stating that strict type checking on enums is more of a pain than a help for programmers. I would claim that if one creates an enum for the days of the week and then store the integer 10000 in an instance of that enum, then you've made a programming mistake -- even if it is permissable according to the language definition. There are a lot of areas in C++ like that -- where the language for historical or pragmatic reasons allows programmers to do things that are generally very bad programming practice. I believe it is important that programs "scan" right to human readers -- if a variable claims to be of a certain enum, it should only hold legal values of that enum. To do otherwise is a bug. IMHO.
franka@mentor.com (Frank A. Adrian) (01/11/90)
In article <418@ns-mx.uiowa.edu> williams@umaxc.weeg.uiowa.edu.UUCP (Kent Williams) writes: >I just received what was recently referred to as the "Ugly Reddish >Book"... >Incidentally, they sent me the wrong book... >The funny thing was she didn't want me to mail the wrong book back >because it 'wasn't worth it.' I think I've discovered some sort >of economic diode! And now we know why ATT has to resort to suing MCI instead of providing service to make money. Just my own grumpy opinion... Frank A. Adrian Mentor Graphics, Inc. franka@mntgfx.com
comeau@utoday.UUCP (Greg Comeau) (01/12/90)
In article <10215@microsoft.UUCP> jimad@microsoft.UUCP (JAMES ADCOCK) writes: >I would claim that if one creates an enum for the days >of the week and then store the integer 10000 in an instance of that >enum, then you've made a programming mistake -- even if it is permissable >according to the language definition. There are a lot of areas in C++ >like that -- where the language for historical or pragmatic reasons allows >programmers to do things that are generally very bad programming practice. At least the 2.0 spec of C++ is in accordance with your train of though and therefore such an assignment is prohibited. ANSI C does not mention anything about this as far as I can detect (I could be wrong though). -- Greg, Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418 Producers of CC C++, SysAdm columnist for UNIX Today!, Microsoft Systems Journal (C programming), + others. Also, BIX c.language & c.plus.plus conf. moderator. Here:attmail!csanta!greg / BIX:comeau / CIS:72331, 3421 / voice:718-849-2355
jimad@microsoft.UUCP (JAMES ADCOCK) (01/12/90)
>The question of what an enum type "really is", has bedeveled >the concept ever since it was introduced into C. Over the >years a lot has been said, but I believe a consensus finally >emerged and both ANSI C and the most recent C++ reference manual agree >that they are integral types. > >This means that its perfectly sensible to assign arbitrary integer >values to variables of enum type. Hm, are you saying this has changed recently? In my [not very new] reference manual appendix B pg 109 says: enum e { A }; sizeof(A) equals sizeof(e), which need not equal sizeof(int) [unlike ANSI-C] For example, it would not be unreasonable for some compiler on some machine to choose to represent small enums in a byte, in which case assigning an int to such an enum could lead to an unexpected truncation. "Integral" is not the same as "integer." Or has this changed?