11 May
2020
11 May
'20
11:32 p.m.
At Sun, 10 May 2020 17:57:46 -0700, Larry McVoy <lm(a)mcvoy.com> wrote:
Subject: Re: [TUHS] v7 K&R C
Absolutely agreed!
The lameness of typedef (and in how enum is related to typedef) is one
of the saddest parts of C. (The other is the default promotion to int.)
It would be trivial to fix too -- for a "new" C, that is. Making it
backward compatible for legacy code would be tough, even with tooling to
help fix the worst issues. I've seen far too much code that would be
hard to fix by hand, e.g. some that even goes so far as to assume things
like arithmetic on enum values will produce other valid enum values.
Ideally enums could be a value in any native type, including float/double.
On Mon, May 11, 2020 at 10:28 AM
<scj(a)yaccman.com> wrote:
> With respect to enums, there is a feature I've wanted for years: a typed
> typedef. Saying typetdef int foo would make foo an integer, but if you
> passed an ordinary int to something declared as foo it would be an error.
> Even if it was an integer constant unless cast.
Steve, I couldn't agree more, you are 100% right, this is how it should
work. I wanted to like enums because I naively thought they'd have these
semantics but then learned they really aren't any different than a well
managed list of #defines. IMHO, without your semantics, enums are pretty
useless, #define is good
enough and more clear.
Actually that's no longer true with a good modern toolchain, especially
with respect to the debugger. A good debugger can now show the enum
symbol for a (matching) value of a properly typedefed variable.
(In fact I never thouth that a #define macro was more clear, even before
debugger support -- the debugger support just gave me a better excuse to
use to explain my preference!)
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>