Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #18090 > unrolled thread

Mechanism to generate annotated "error codes"

Back to article view | Back to comp.lang.c

Contents

  Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 12:48 -0700
    Re: Mechanism to generate annotated "error codes" Willem <willem@toad.stack.nl> - 2012-03-01 21:29 +0000
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 16:53 -0700
    Re: Mechanism to generate annotated "error codes" William Ahern <william@wilbur.25thandClement.com> - 2012-03-01 14:13 -0800
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 22:07 -0700
    Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-01 17:53 -0500
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-01 23:05 -0700
        Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-02 01:50 -0500
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 00:43 -0700
            Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-03 17:58 -0500
              Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-04 03:16 -0500
                Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 13:47 -0700
              Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 13:45 -0700
                Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-04 18:37 -0500
                  Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 22:12 -0700
                    Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-08 01:41 -0500
                      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-09 14:34 -0700
    Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 00:30 -0700
      Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-02 02:05 -0800
        Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-02 10:47 +0000
        Re: Mechanism to generate annotated "error codes" gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-02 14:18 +0000
        Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 10:46 -0700
          Re: Mechanism to generate annotated "error codes" James Kuyper <jameskuyper@verizon.net> - 2012-03-02 14:08 -0500
            Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 12:38 -0700
          Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-02 22:57 +0000
            Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 17:14 -0700
              Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-03 02:25 +0000
              Re: Mechanism to generate annotated "error codes" James Kuyper <jameskuyper@verizon.net> - 2012-03-03 06:10 -0500
                Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-03 16:12 -0500
          Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-03 04:04 -0800
            Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-03 15:05 +0000
              Re: Mechanism to generate annotated "error codes" Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-03-03 16:25 +0000
            Re: Mechanism to generate annotated "error codes" Shao Miller <sha0.miller@gmail.com> - 2012-03-03 16:26 -0500
              Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-03 13:40 -0800
        Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-03 12:03 +1300
          Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-02 15:45 -0800
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-02 17:18 -0700
        Re: Mechanism to generate annotated "error codes" blp@cs.stanford.edu (Ben Pfaff) - 2012-03-02 15:08 -0800
        Re: Mechanism to generate annotated "error codes" "BartC" <bc@freeuk.com> - 2012-03-03 10:30 +0000
          Re: Mechanism to generate annotated "error codes" James Kuyper <jameskuyper@verizon.net> - 2012-03-03 06:19 -0500
          Re: Mechanism to generate annotated "error codes" Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-03-03 15:15 +0200
          Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-03 14:52 +0000
            Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 07:39 -0800
              Re: Mechanism to generate annotated "error codes" Jonathan Leffler <jleffler@earthlink.net> - 2012-03-03 23:56 -0800
                Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 09:20 +1300
                  Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-04 13:28 -0800
                    Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 10:56 +1300
            Re: Mechanism to generate annotated "error codes" "BartC" <bc@freeuk.com> - 2012-03-03 17:02 +0000
          Re: Mechanism to generate annotated "error codes" Keith Thompson <kst-u@mib.org> - 2012-03-03 12:30 -0800
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 19:15 -0700
        Re: Mechanism to generate annotated "error codes" Kaz Kylheku <kaz@kylheku.com> - 2012-03-04 03:20 +0000
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 11:03 -0700
        Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 16:31 -0700
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 23:04 -0700
    Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-02 22:13 -0800
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 00:49 -0700
        Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 03:32 -0800
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 12:04 -0700
            Re: Mechanism to generate annotated "error codes" Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-03 15:06 -0500
              Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 14:38 -0700
            Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 12:15 -0800
              Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 16:51 -0700
                Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-04 14:08 -0800
                  Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 15:56 -0700
        Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 03:45 -0800
          Re: Mechanism to generate annotated "error codes" Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-03-03 14:11 -0500
            Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 13:03 -0700
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 12:32 -0700
        Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 15:04 -0700
          Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-04 11:09 +1300
            Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 16:55 -0700
              Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-04 13:04 +1300
                Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 18:24 -0700
          Re: Mechanism to generate annotated "error codes" Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-03-03 14:30 -0800
            Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-03 17:06 -0700
    Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 10:09 +1300
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 16:03 -0700
        Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 13:26 +1300
          Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-04 22:21 -0700
            Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-05 20:46 +1300
              Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-05 10:54 -0700
                Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-06 10:02 +1300
                  Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-05 16:09 -0700
              Re: Mechanism to generate annotated "error codes" "BartC" <bc@freeuk.com> - 2012-03-06 10:54 +0000
                Re: Mechanism to generate annotated "error codes" Ian Collins <ian-news@hotmail.com> - 2012-03-07 07:22 +1300
    Re: Mechanism to generate annotated "error codes" gordonb.8sa24@burditt.org (Gordon Burditt) - 2012-03-06 08:51 -0600
      Re: Mechanism to generate annotated "error codes" Don Y <this@isnotme.com> - 2012-03-06 11:21 -0700

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#18108

In article <lnr4xb71y6.fsf@nuthaus.mib.org>,
Keith Thompson  <kst-u@mib.org> wrote:
>Don Y <this@isnotme.com> writes:
>[...]
>> You need to maintain this "by hand".  There is nothing that
>> prevents you from:
>>    #define YES  (2)
>>    #define NO   (2)
>>
>> Nor:
>>    #define YES (2)
>>    ...
>>    #define ABSOLUTELY  (27)
>> (assuming yes and absolutely are synonyms)
>[...]
>
>A minor point: parenthesizing macro definitions is a good habit, but
>it's not necessary when the macro expands to a single token.  This:
>
>    #define ABSOLUTELY 27
>
>is just as safe as
>
>    #define ABSOLUTELY (27)

Much as I hate to disagree with Leader Kiki, I have to take exception to
this.  If there is a corporate requirement that all macro definitions be
parenthesized, as is probably the case in many workplaces, then not
parenthesizing exposes the coder to the risk of ending up on the
unemployment line.

Hardly safe by my lights...

-- 
Just for a change of pace, this sig is *not* an obscure reference to
comp.lang.c...

[toc] | [prev] | [next] | [standalone]

#18117

Hi Keith,

On 3/2/2012 3:05 AM, Keith Thompson wrote:

> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token.  This:

Keeping a gun's safety "on" is "a good habit".  Do you often
leave it *off* just because you don't *think* you need it
"on" at the present time?  Or, do you wait until you
really *need* it "off" (i.e., just prior to discharge)?

Good habits are kept -- as a matter of HABIT!  :>

[toc] | [prev] | [next] | [standalone]

#18119

On 03/02/2012 12:46 PM, Don Y wrote:
> Hi Keith,
> 
> On 3/2/2012 3:05 AM, Keith Thompson wrote:
> 
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token.  This:
> 
> Keeping a gun's safety "on" is "a good habit".  Do you often
> leave it *off* just because you don't *think* you need it
> "on" at the present time?  Or, do you wait until you
> really *need* it "off" (i.e., just prior to discharge)?
> 
> Good habits are kept -- as a matter of HABIT!  :>

I check my keys every time I go out the door of my house, as a matter of
habit, even if I don't intend to lock the door. That's a good habit.
People with OCD might check their keys each time they go out the bedroom
door, even if it doesn't have a lock. That's not a good habit, that's a
waste of time. In extreme cases, people with OCD waste so much time
checking things that don't need to be checked, that they never get
anything useful done with their life.

Parentheses convert other kinds of expressions into primary expressions.
Macro expansions that are already primary expressions (identifiers,
constants, string literals, and generic selections* - 6.5.1) - don't
need parentheses. Parenthesizing them is closer to the OCD end of the
spectrum, than to the good habit end.

*Generic selections are a new feature of C2011.

[toc] | [prev] | [next] | [standalone]

#18120

Hi James,

On 3/2/2012 12:08 PM, James Kuyper wrote:

>>> A minor point: parenthesizing macro definitions is a good habit, but
>>> it's not necessary when the macro expands to a single token.  This:
>>
>> Keeping a gun's safety "on" is "a good habit".  Do you often
>> leave it *off* just because you don't *think* you need it
>> "on" at the present time?  Or, do you wait until you
>> really *need* it "off" (i.e., just prior to discharge)?
>>
>> Good habits are kept -- as a matter of HABIT!  :>
>
> I check my keys every time I go out the door of my house, as a matter of
> habit, even if I don't intend to lock the door. That's a good habit.
> People with OCD might check their keys each time they go out the bedroom
> door, even if it doesn't have a lock. That's not a good habit, that's a
> waste of time. In extreme cases, people with OCD waste so much time
> checking things that don't need to be checked, that they never get
> anything useful done with their life.

OCD interferes with your goal -- "living".

> Parentheses convert other kinds of expressions into primary expressions.
> Macro expansions that are already primary expressions (identifiers,
> constants, string literals, and generic selections* - 6.5.1) - don't
> need parentheses. Parenthesizing them is closer to the OCD end of the
> spectrum, than to the good habit end.

I guess I don't see two extra keystrokes on a #define as interfering
with my goal (of writing reliable code that others can maintain).
I've already invested 10 keystrokes ("#define " the whitespace between 
the symbol and its definition and the trailing '\n') and will invest
at least 2 more (assuming the symbol and definition are each just 1).
Increasing that "overhead" from 12 to 14 is pocket change.

OTOH, I can't count the number of times I've had to step in and
"fix" someone's "minor tweek" of a running program when they
changed:
   #define PHONE_NUMBER_DIGITS 7
to:
   #define PHONE_NUMBER_DIGITS 3+7
And then have to *explain* the reason behind the *need* for the parens:
   "So, if I just said '10', instead, I wouldn't have had the problem
   AND wouldn't have had to type the parens?  I guess I should just
   type '10' in the future..."
   "No, the problem with *that*, is..."

I can't speak for you but *I* sure don't like wasting my time on
that sort of after-the-fact annoyance.

Of course, you're free to live with whatever coding style you
(and your clients/employers) find suitable for the projects
and personnel available to you.

You could also build giant tables of #define's to represent all
of the possible error codes that routines in your project can
throw!  :>

[I'd really prefer to address the subject of my OP.  Missing the
forest for the trees is a sure-fire "waste of time"  :>]

[toc] | [prev] | [next] | [standalone]

#18122

On 2012-03-02, Don Y <this@isnotme.com> wrote:
> Hi Keith,
>
> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token.  This:
>
> Keeping a gun's safety "on" is "a good habit".  Do you often
> leave it *off* just because you don't *think* you need it
> "on" at the present time?  Or, do you wait until you
> really *need* it "off" (i.e., just prior to discharge)?

Do you often modify your gun to a completely different model,
and without touching the safety switch?

[toc] | [prev] | [next] | [standalone]

#18130

Hi Kaz,

On 3/2/2012 3:57 PM, Kaz Kylheku wrote:
> On 2012-03-02, Don Y<this@isnotme.com>  wrote:
>> Hi Keith,
>>
>> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>>
>>> A minor point: parenthesizing macro definitions is a good habit, but
>>> it's not necessary when the macro expands to a single token.  This:
>>
>> Keeping a gun's safety "on" is "a good habit".  Do you often
>> leave it *off* just because you don't *think* you need it
>> "on" at the present time?  Or, do you wait until you
>> really *need* it "off" (i.e., just prior to discharge)?
>
> Do you often modify your gun to a completely different model,
> and without touching the safety switch?

Is there NO possibility of someone OTHER THAN YOU having access
to that weapon?  Someone who doesn't have the same sense of
discipline that you *might*?

You would adopt the same HABIT with the new weapon.  Habits are
things that you shouldn't have to PAUSE AND THINK ABOUT.  Do
you *consciously* think about the semicolon at the end of each
source statement?  Do you *consciously* think about the parens
following a function invocation?

E.g., I only consciously think about semicolons on empty
statements.  And, since these are so atypical, it gives me
reason to pause and DRAW ATTENTION to these "/* EMPTY */"
statements.

You shouldn't have to ask yourself, "Should I put the safety
on, now?".  You should do it without thinking.

"Should I parenthesize this definition?"

The "stop and think" action should be the exception leading
to the more "risky" behavior:  "Do I *really* want to be ready
to KILL someone?"

"Is there some reason why I *shouldn't* parenthesize?"

Establish behaviors that tend to decrease the chances of
people making undetected (or, expensive to detect) mistakes.
The compiler will complain if you add parens somewhere that
violates syntactic requirements.  It *won't* if you fail to
add the parens.  (yes, a friendly compiler can warn you
of this possibility -- but, doesn't *have* to)

IME, people mimic the styles and practices of the code
they are maintaining.  You play fast and loose with how
you write things and you invite others to do the same.

You will note that the solution I am using from the original
post (Hmmm... original post?  What's *that*?!) did not expose
#defines to the developer.  It intentionally hid the "how's"
of the mechanism from the developer while providing the
desired functionality.  The MakeErrorCode mechanism can be
implemented any way I choose -- so long as the code it
generates (none) is predictable and the functionality desired
is present.  E.g., all I need to do is make sure the compiler
(when *it* sees the code "for real") knows how to resolve
"Err_TooManyDecimalPoints" -- whether as a manifest constant,
extern variable, a substitution performed by the preprocessor
(or other agent), etc.

Build a mechanism that is easy for others to adopt so that
it is easier for them to continue that behavior than to
come up with a different, ad hoc approach on their own.
(e.g., the *expensive* mechanism of storing error messages
in a real database instead of ad hoc strings littered through
the code and ad hoc mechanisms for presenting them to the user.)

Of course, if you're the only one maintaining your code
or can be assured people AT LEAST as competent as you
are the only ones that it is exposed to, you can get away
with whatever you want.  I find that in heavily regulated
industries and large projects (100's of KLoC's), folks seem
to want to err on the side of more "consistency" than "less".

[toc] | [prev] | [next] | [standalone]

#18132

On 2012-03-03, Don Y <this@isnotme.com> wrote:
> Hi Kaz,
>
> On 3/2/2012 3:57 PM, Kaz Kylheku wrote:
>> On 2012-03-02, Don Y<this@isnotme.com>  wrote:
>>> Hi Keith,
>>>
>>> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>>>
>>>> A minor point: parenthesizing macro definitions is a good habit, but
>>>> it's not necessary when the macro expands to a single token.  This:
>>>
>>> Keeping a gun's safety "on" is "a good habit".  Do you often
>>> leave it *off* just because you don't *think* you need it
>>> "on" at the present time?  Or, do you wait until you
>>> really *need* it "off" (i.e., just prior to discharge)?
>>
>> Do you often modify your gun to a completely different model,
>> and without touching the safety switch?
>
> Is there NO possibility of someone OTHER THAN YOU having access
> to that weapon?  Someone who doesn't have the same sense of
> discipline that you *might*?

Since #def SYM 27 is perfectly safe when accessed, this analogy falls
flat on its face, too.

> You would adopt the same HABIT with the new weapon.  Habits are
> things that you shouldn't have to PAUSE AND THINK ABOUT.

Someone else's good habit is not writing parentheses around single tokens.

It's only a tiny bit more complex than the naive habit of always doing it, but
it's still a habit.

In a car, you have two pedals operated with the same foot that do something
quite opposite, yet your brain can generally work out which to use.
You don't think, "I want to slow down; is it the left one?"

[toc] | [prev] | [next] | [standalone]

#18137

On 03/02/2012 07:14 PM, Don Y wrote:
> Hi Kaz,
> 
> On 3/2/2012 3:57 PM, Kaz Kylheku wrote:
>> On 2012-03-02, Don Y<this@isnotme.com>  wrote:
>>> Hi Keith,
>>>
>>> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>>>
>>>> A minor point: parenthesizing macro definitions is a good habit, but
>>>> it's not necessary when the macro expands to a single token.  This:
...
> "Is there some reason why I *shouldn't* parenthesize?"

Well, Ben Pfaff has provided one example where parenthesizing a macro
definition interferes with it's intended usage. A parenthesized string
literal is not a string literal, and will therefore not be merged with
adjacent string literals. Many string literal macros are intended to be
used in the construction of larger string literals, so parenthesizing
them would interfere with that use case.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#18163

On 3/3/2012 06:10, James Kuyper wrote:
> Well, Ben Pfaff has provided one example where parenthesizing a macro
> definition interferes with it's intended usage.

ITS ITS ITS ITS ITS ITS ITS

"it's" == "it is"
"its" implies ownership.

[toc] | [prev] | [next] | [standalone]

#18141

Don Y <this@isnotme.com> writes:
> Hi Keith,
> On 3/2/2012 3:05 AM, Keith Thompson wrote:
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token.  This:
>
> Keeping a gun's safety "on" is "a good habit".  Do you often
> leave it *off* just because you don't *think* you need it
> "on" at the present time?  Or, do you wait until you
> really *need* it "off" (i.e., just prior to discharge)?
>
> Good habits are kept -- as a matter of HABIT!  :>

For the most part, I tend to agree with your point about good habits.
For example, I consistently use curly braces on compound statements
whether they're necessary or not; I write:

    if (cond) {
        stmt;
    }

rather than

    if (cond)
        stmt;

But for parenthesizing macro definitions, I don't agree.  When I define
a macro whose expansion is to be used as an expression, I put
parentheses around the whole expansion and around each parameter
reference.

Mostly.

But if the entire expansion is a single token, I don't bother with the
parentheses:

    #define ANSWER 42

nor do I parenthesize a parameter reference if it's immediately
surrounded by parentheses or square brackets:

    #define ELEM(i) (arr[i])

Why?  Because I find the fact that the parentheses are unnecessary
in this case to be sufficiently obvious that omitting them doesn't
bother me, and if I change the definition later I'm not going to
forgot to add parentheses if they're needed:

    #define ANSWER (6*9)

I don't claim to be entirely consistent on this point.  The reasoning
that leads me to use curly braces in all cases is pretty much the same
reasoning that I ignore for single-token macro definitions.

You haven't changed my mind, but you have forced me to think about the
issue.  Thank you for that.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#18146

On 2012-03-03, Keith Thompson <kst-u@mib.org> wrote:
> nor do I parenthesize a parameter reference if it's immediately
> surrounded by parentheses or square brackets:
>
>     #define ELEM(i) (arr[i])
>
> Why?  Because I find the fact that the parentheses are unnecessary
> in this case to be sufficiently obvious that omitting them doesn't

It's not that parentheses are unnecessary here, it's rather that [i] has them
already, in the form of square brackets.

Syntactically, braces do exactly the same job of delimiting a phrase unit as
do parentheses.

In either (i) or [i], the i material has been placed into a phrase structure
rule where it is guarded by a pair of nonterminal symbols, and so the parser
cannot possibly break i into pieces that get folded incorrectly into
surrounding syntax.

Though [E] is not a primary expression by itself, that is irrelevant to the
issue.

[toc] | [prev] | [next] | [standalone]

#18150

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2012-03-03, Keith Thompson <kst-u@mib.org> wrote:
>> nor do I parenthesize a parameter reference if it's immediately
>> surrounded by parentheses or square brackets:
>>
>>     #define ELEM(i) (arr[i])
>>
>> Why?  Because I find the fact that the parentheses are unnecessary
>> in this case to be sufficiently obvious that omitting them doesn't
>
> It's not that parentheses are unnecessary here, it's rather that [i] has them
> already, in the form of square brackets.
>
> Syntactically, braces do exactly the same job of delimiting a phrase unit as
> do parentheses.
>
> In either (i) or [i], the i material has been placed into a phrase structure
> rule where it is guarded by a pair of nonterminal symbols, and so the
> parser cannot possibly break i into pieces that get folded incorrectly into
> surrounding syntax.

(Did you mean "terminal symbols" here?)

The trouble is that C's macros are not syntactic.  Thus

  ELEM(i][0)

is "valid".  This might be considered a rare enough error (or one that
is so likely to be picked up elsewhere) that it can be ignored, but it
does show that there is an argument, however weak, for writing

  #define ELEM (arr[(i)])

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#18165

On 3/3/2012 07:04, Keith Thompson wrote:
>
>      #define ANSWER (6*9)
>

I think you meant:

   #define ANSWER (6 * 7)

[toc] | [prev] | [next] | [standalone]

#18168

Shao Miller <sha0.miller@gmail.com> writes:
> On 3/3/2012 07:04, Keith Thompson wrote:
>>
>>      #define ANSWER (6*9)
>>
>
> I think you meant:
>
>    #define ANSWER (6 * 7)

I think you need to read "The Hitchhiker's Guide to the Galaxy", by
Douglas Adams.  42 is given as "the ultimate answer to life, the
universe, and everything".  It's eventually discovered that the question
is "What do you get when you multiply six by nine", demonstrating that
there's something fundamentally wrong with the universe.

See also <https://github.com/Keith-S-Thompson/42>.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#18126

On 03/ 2/12 11:05 PM, Keith Thompson wrote:
> Don Y<this@isnotme.com>  writes:
> [...]
>> You need to maintain this "by hand".  There is nothing that
>> prevents you from:
>>     #define YES  (2)
>>     #define NO   (2)
>>
>> Nor:
>>     #define YES (2)
>>     ...
>>     #define ABSOLUTELY  (27)
>> (assuming yes and absolutely are synonyms)
> [...]
>
> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token.  This:
>
>      #define ABSOLUTELY 27
>
> is just as safe as
>
>      #define ABSOLUTELY (27)

Or simply don't use macros for constants!

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#18129

Ian Collins <ian-news@hotmail.com> writes:
> On 03/ 2/12 11:05 PM, Keith Thompson wrote:
>> Don Y<this@isnotme.com>  writes:
>> [...]
>>> You need to maintain this "by hand".  There is nothing that
>>> prevents you from:
>>>     #define YES  (2)
>>>     #define NO   (2)
>>>
>>> Nor:
>>>     #define YES (2)
>>>     ...
>>>     #define ABSOLUTELY  (27)
>>> (assuming yes and absolutely are synonyms)
>> [...]
>>
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token.  This:
>>
>>      #define ABSOLUTELY 27
>>
>> is just as safe as
>>
>>      #define ABSOLUTELY (27)
>
> Or simply don't use macros for constants!

27!.  Um, I mean ABSOLUTELY!  8-)}

But note that declaring:

    const int ABSOLUTELY = 27;

gives you something that you can't use where a constant expression
is required, nor can you meaningfully use it in a #if directive.
For values in the range of int, you can work around that by using
an enum:

    enum { ABSOLUTELY = 27 };

(In either case, you probably wouldn't use all-caps for the name.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#18131

Hi Ian,

On 3/2/2012 4:03 PM, Ian Collins wrote:
> On 03/ 2/12 11:05 PM, Keith Thompson wrote:
>> Don Y<this@isnotme.com> writes:

>>> You need to maintain this "by hand". There is nothing that
>>> prevents you from:
>>> #define YES (2)
>>> #define NO (2)
>>>
>>> Nor:
>>> #define YES (2)
>>> ...
>>> #define ABSOLUTELY (27)
>>> (assuming yes and absolutely are synonyms)
>> [...]
>>
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token. This:
>>
>> #define ABSOLUTELY 27
>>
>> is just as safe as
>>
>> #define ABSOLUTELY (27)
>
> Or simply don't use macros for constants!

Or, as described in my "solution", *hide* all of that mechanism from
the developer!  *Don't* build large tables MANUALLY with bogus
constants in them.  Let the machine do what it does best -- simple,
repetitive tasks (like expanding MakeErrorCode into something
useful for the functionality it provides).

[toc] | [prev] | [next] | [standalone]

#18127

Keith Thompson <kst-u@mib.org> writes:

> Don Y <this@isnotme.com> writes:
> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token.  This:
>
>     #define ABSOLUTELY 27
>
> is just as safe as
>
>     #define ABSOLUTELY (27)

Furthermore,

      #define PRIx64 "llx"

is far more useful than

      #define PRIx64 ("llx")
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[toc] | [prev] | [next] | [standalone]

#18136

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnr4xb71y6.fsf@nuthaus.mib.org...
> Don Y <this@isnotme.com> writes:
> [...]
>> You need to maintain this "by hand".  There is nothing that
>> prevents you from:
>>    #define YES  (2)
>>    #define NO   (2)
>>
>> Nor:
>>    #define YES (2)
>>    ...
>>    #define ABSOLUTELY  (27)
>> (assuming yes and absolutely are synonyms)
> [...]
>
> A minor point: parenthesizing macro definitions is a good habit, but
> it's not necessary when the macro expands to a single token.  This:
>
>    #define ABSOLUTELY 27
>
> is just as safe as
>
>    #define ABSOLUTELY (27)

What happens when someone experiments with the value 27 by trying this:

    #define ABSOLUTELY 27+1

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#18138

On 03/03/2012 05:30 AM, BartC wrote:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnr4xb71y6.fsf@nuthaus.mib.org...
...
>> A minor point: parenthesizing macro definitions is a good habit, but
>> it's not necessary when the macro expands to a single token.  This:
>>
>>    #define ABSOLUTELY 27
>>
>> is just as safe as
>>
>>    #define ABSOLUTELY (27)
> 
> What happens when someone experiments with the value 27 by trying this:
> 
>     #define ABSOLUTELY 27+1

The same thing that happens when somebody experiments as follows:

	#define ABSOLUTELY (27)+1

Or

	#define ABSOLUTELY (27)+(1)

If someone doesn't understand why the parenthesis are unnecessary for
(27), then that person can't be counted on to understand whey they are
necessary in (27+1). For such a person, it may be best to parenthesize
everything, just to be safe - the compiler will almost certainly
complain if someone attempts string literal merging with a parenthesized
string literal. I think it's preferable, however, to gain the small
amount of additional understanding needed to realize why (27) is in fact
unnecessary, and ("Absolutely") may actually be a problem.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web