From: Bill Davidsen <davidsen@tmr.com>
To: Coywolf Qi Hunt <coywolf@gmail.com>
Cc: "linux-os (Dick Johnson)" <linux-os@analogic.com>,
Paul Jackson <pj@sgi.com>,
francis_moreau2000@yahoo.fr, linux-kernel@vger.kernel.org
Subject: Re: Use enum to declare errno values
Date: Fri, 02 Dec 2005 13:15:57 -0500 [thread overview]
Message-ID: <43908F5D.6070607@tmr.com> (raw)
In-Reply-To: <2cd57c900512020907h4be23519q@mail.gmail.com>
Coywolf Qi Hunt wrote:
>2005/12/3, Bill Davidsen <davidsen@tmr.com>:
>
>
>>Coywolf Qi Hunt wrote:
>>
>>
>>
>>>This is a reason why enums are worse than #defines.
>>>
>>>Unlike in other languages, C enum is not much useful in practices.
>>>
>>>
>>Actually they are highly useful if you know how to use them. They allow
>>type checking, have auto increment, and are part of the language instead
>> of a feature of the preprocessor.
>>
>>
>
>Yes, I know type checking and auto increment. But they are not
>worthwhile, at least not for serious C programming. No, I don't know
>how to use them comfortably.
>
>
Type checking is not useful for serious C programming? Really?
>What's wrong with sorted macros? They are more flexible and readable.
>enums just look weird. We also share macros b/w C and asm.
>
>You words on language and preprocessor doesn't make any sense.
>
>
They highlight the difference. The preprocessor is a form of text
editor, which only knows what the source *says* but not what it *means*.
The compiler knows about types, common subexpressions, etc.
>It's not a feature of the preprocessor, it's what cpp is for. Look, I
>call it Cpp. Without this `feature', what would a C preprocessor do?
>You've castrated cpp.
>
>Follow you logic, C standard should only specify C language, not
>anything of libc... I have no interest in arguing the relations b/w C
>and cpp.
>
>
The standard should specify the source language and it's meaning. The
fact that it specifies what cpp does (text editing) as well is for
convenience. The language works the same whether you write it with vi or
cpp, cpp is just more convenient that sed ;-)
>
>
>>>Maybe the designer wanted C to be as fancy as other languages? C
>>>shouldn't have had enum imho. Anyway we don't have any strong motives
>>>to switch to enums.
>>>
>>>
>>The last sentence seems correct in spite of your misunderstanding of how
>>and why enums are used and useful. Like a driver who mis-read a map
>>wandering aimlessly and lost, you have come to the correct destination
>>by accident.
>>
>>
>
>lol
>
>
>
>>It would have been good to use enums in the first place, I can't see
>>changing now because of the effort involved.
>>
>>
>
>You contradict yourself rather.
>
>
Not at all... enum would have been better, but not so much better that
it's worth doing over.
--
bill davidsen <davidsen@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
next prev parent reply other threads:[~2005-12-02 18:03 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-23 13:24 Use enum to declare errno values moreau francis
2005-11-23 14:19 ` linux-os (Dick Johnson)
2005-11-23 14:24 ` Denis Vlasenko
2005-11-23 15:00 ` linux-os (Dick Johnson)
2005-11-24 7:19 ` Denis Vlasenko
2005-11-24 7:30 ` Paul Jackson
2005-11-24 7:37 ` Paul Jackson
2005-12-01 20:01 ` linux-os (Dick Johnson)
2005-12-02 6:49 ` Denis Vlasenko
2005-12-02 9:27 ` Coywolf Qi Hunt
2005-12-02 12:07 ` Denis Vlasenko
2005-12-02 12:18 ` Pekka Enberg
2005-12-02 12:56 ` Coywolf Qi Hunt
2005-12-02 13:20 ` Denis Vlasenko
2005-12-02 13:34 ` Pekka Enberg
2005-12-02 16:02 ` Bill Davidsen
2005-12-02 16:32 ` Coywolf Qi Hunt
2005-12-02 16:56 ` Vadim Lobanov
2005-12-04 13:10 ` Denis Vlasenko
2005-12-02 16:15 ` Bill Davidsen
2005-12-02 17:07 ` Coywolf Qi Hunt
2005-12-02 17:51 ` Steven Rostedt
2005-12-02 18:15 ` Bill Davidsen [this message]
2005-12-02 18:30 ` Horst von Brand
2005-11-23 14:27 ` Denis Vlasenko
2005-11-23 14:31 ` Denis Vlasenko
2005-11-23 15:15 ` Alan Cox
2005-11-23 15:44 ` moreau francis
2005-11-23 15:55 ` Nikita Danilov
2005-11-23 16:05 ` moreau francis
2005-11-23 16:24 ` Nikita Danilov
2005-11-23 16:42 ` moreau francis
2005-11-23 16:54 ` Nikita Danilov
2005-11-24 7:22 ` Denis Vlasenko
2005-11-23 17:35 ` Bill Davidsen
2005-11-24 9:43 ` Giuliano Pochini
2005-11-28 23:19 ` Bill Davidsen
2005-11-24 17:11 ` Ben Pfaff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43908F5D.6070607@tmr.com \
--to=davidsen@tmr.com \
--cc=coywolf@gmail.com \
--cc=francis_moreau2000@yahoo.fr \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.com \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.