root@odi.com (Operator) (06/28/89)
In ANSI C, it is ( I thought) legitimate to do the following:
enum x { a, b, c} y;
int i;
y = 1;
i = y;
In the 2.0 release version of c++, a warning is emitted
for assigments of int typed to enums.
In theory, benign warnings are supposed to be suppressed
unless one compiles with the +w option.
Howcome this isn't suppressed?bs@alice.UUCP (Bjarne Stroustrup) (06/30/89)
root@odi.com (Operator) from Object Design Inc., Burlington, MA writes: > In ANSI C, it is ( I thought) legitimate to do the following: > > enum x { a, b, c} y; > int i; > > y = 1; > i = y; It is. > In the 2.0 release version of c++, a warning is emitted > for assigments of int typed to enums. > > In theory, benign warnings are supposed to be suppressed > unless one compiles with the +w option. > > Howcome this isn't suppressed? In C++, the example is not legal. There is no standard conversion from int to enums so the example is an error: enum x { a, b, c} y; int i; f() { y = 1; // error: int assigned to enum x, no standard conversion i = y; // ok standard conversion of enum to int } However, for compatibility only a warning is issued by 2.0: "", line 7: warning: int assigned to enum x The reason to disallow implicit conversions from int to enumerations in C++ (despite SOME cases being safe and SOME cases being legal ANSI C) is that only a few cases can be verified to be safe at compile time. For example: y = 1; // safe b==1 y = b; // better y = 4; // safe? It is legal ANSI C (I'm pretty sure) y = 1000; // safe? It is not guaranteed by ANSI C (I'm pretty sure) y = 1000000; // safe? not on your average computer. y = i; // safe? depends on the value of i. Rather than trying to cope with the insecurities by run-time checking (which would be most un-C-like) or simply allow whole classes of preventable errors (which would be most un-C++-like) we decided to base to rule on type alone (and not on the values). If you really want those assignments you can suppress any unwanted compiler interference: y = x(1); y = b; // better y = x(4); y = x(1000); y = x(1000000); y = x(i); Gradually introducing this rule by first using a warning and later turning it into an error seems prudent. If you find that too feeble, you might use the +p (`p' for `pure') option and get: "", line 7: error: int assigned to enum x The change of enumerations from mere typedefs for ints to types was done to bring C++ closer in line with modern C compilers and ANSI C.
benson@odi.com (Benson Margulies) (07/04/89)
In article <9552@alice.UUCP> ark@alice.UUCP (Andrew Koenig) writes: >At present C++ is consistent in not allowing any user-defined >conversions on built-in types. Thus instead of using an enum, >you'd have to use a class with an enum member. > I think that there is another sort of consistency problem here. If you hadn't added any type safety to the builtin types, then all would be as in plain C. However, you have added type safety restrictions to enums. To my mind, that requires controls on the type safety -- user-defined conversions. I can define conversions willy-nilly for classes. I can assign ints to shorts to longs to my heart's content. But I can neither assign an int to an enum without an explicit conversion nor can I define a conversion to obviate the need. Its like one little bit of ada (or Eiffle :-) ) in the middle of C. -- Benson I. Margulies
ark@alice.UUCP (Andrew Koenig) (07/04/89)
In article <390@odi.ODI.COM>, benson@odi.com (Benson Margulies) writes: > I can define conversions willy-nilly for > classes. I can assign ints to shorts to longs to my heart's content. Not really -- you'll get a warning if you assign a long to an int, too. -- --Andrew Koenig ark@europa.att.com
benson@odi.com (Benson Margulies) (08/08/89)
I was playing radical (the root, that is) when I posted the question about enums. I am pretty much convinced by the existence of the convienient conversion operators. I have two trailing thoughts: 1) It sure would be nice to be able to define implicit conversions involving ints and enums. They could even include runtime checking! 2) You might be amused in how I got into this. For ease of debugging work I am doing to c++ itself, I defined the type TOK to be a real live enum of the token types. So my friendly debugger can print token names instead of numbers. Well, I got about 50 warnings about assignments of 0 or ints or chars to TOK's! So I was looking madly for a way to preserve the debugging enhancement and shut up the warnings other than to fix all of the offending uses of TOK in the entire cfront source. -- Benson I. Margulies
ark@alice.UUCP (Andrew Koenig) (08/08/89)
In article <389@odi.ODI.COM>, benson@odi.com (Benson Margulies) writes: > 1) It sure would be nice to be able to define implicit conversions > involving ints and enums. They could even include runtime checking! At present C++ is consistent in not allowing any user-defined conversions on built-in types. Thus instead of using an enum, you'd have to use a class with an enum member. There are many arguments for allowing redefinition of built-in operations, but also many arguments against. -- --Andrew Koenig ark@europa.att.com
ark@alice.UUCP (Andrew Koenig) (08/14/89)
In article <389@odi.ODI.COM>, benson@odi.com (Benson Margulies) writes: > 1) It sure would be nice to be able to define implicit conversions > involving ints and enums. They could even include runtime checking! Why not make your type a class with the appropriate conversions? -- --Andrew Koenig ark@europa.att.com
nagle@well.UUCP (John Nagle) (08/14/89)
In article <389@odi.ODI.COM> benson@odi.com (Benson Margulies) writes:
- 2) You might be amused in how I got into this. For ease of debugging
- work I am doing to c++ itself, I defined the type TOK to be a real
- live enum of the token types. So my friendly debugger can print
- token names instead of numbers. Well, I got about 50 warnings
- about assignments of 0 or ints or chars to TOK's! So I was looking
- madly for a way to preserve the debugging enhancement and shut up the
- warnings other than to fix all of the offending uses of TOK in the entire
- cfront source.
Adding a language feature to support bad code is generally not desirable.
John Naglebenson@odi.com (Benson I. Margulies) (08/16/89)
In article <13131@well.UUCP> nagle@well.UUCP (John Nagle) writes: >In article <389@odi.ODI.COM> benson@odi.com (Benson Margulies) writes: > >- 2) You might be amused in how I got into this. For ease of debugging >- work I am doing to c++ itself, I defined the type TOK to be a real >- live enum of the token types. So my friendly debugger can print >- token names instead of numbers. Well, I got about 50 warnings >- about assignments of 0 or ints or chars to TOK's! So I was looking >- madly for a way to preserve the debugging enhancement and shut up the >- warnings other than to fix all of the offending uses of TOK in the entire >- cfront source. > > Adding a language feature to support bad code is generally not desirable. > > John Nagle Can someone explain why a transaction I posted months ago is suddenly provoking a new crop of replies? by the way, the above-quoted passage was something of an inside joke. You have to be one of us people that works on the insides of cfront to understand it. It was not intended to sway anyone's opinion about the original question. I thought my serious arguments on that front were fairly good, but if they failed to convince then they failed to convince. -- Benson I. Margulies