Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!cs.utexas.edu!uunet!odi!benson From: benson@odi.com (Benson I. Margulies) Newsgroups: comp.lang.c++ Subject: Re: assigning int to enum Message-ID: <1989Aug16.123503.7182@odi.com> Date: 16 Aug 89 12:35:03 GMT References: <387@odi.ODI.COM> <9550@alice.UUCP> <389@odi.ODI.COM> <13131@well.UUCP> Reply-To: benson@odi.com (Benson I. Margulies) Organization: Object Design Inc., Burlington, MA Lines: 28 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