A code snippet

Discussion in 'C Programming' started by Phil Carmody, Nov 4, 2009.

  1. Phil Carmody

    Phil Carmody Guest

    I post this with minimal comment.

    Do not infer anything from the token names, you may pretend I named
    them to mislead you etc. Please ignore whitespace wherever possible,
    I just tabbed randomly.

    // ... includes, and all that jazz elided

    if (x
    #ifdef EQUALITY_PERMITTED
    <=
    #else
    <
    #endif
    UPPERBOUND) {
    // kyrie elision
    }

    Which circle of hell does the above reside in? For how many reasons
    should the above be avoided? What could go wrong?

    Phil
    --
    Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
    Phil Carmody, Nov 4, 2009
    #1
    1. Advertising

  2. Phil Carmody

    Seebs Guest

    On 2009-11-04, Phil Carmody <> wrote:
    > // ... includes, and all that jazz elided
    >
    > if (x
    > #ifdef EQUALITY_PERMITTED
    > <=
    > #else
    > <
    > #endif
    > UPPERBOUND) {
    > // kyrie elision
    > }


    Ugh.

    > Which circle of hell does the above reside in? For how many reasons
    > should the above be avoided? What could go wrong?


    It's probably fine as-is, except that if it ever needs to be changed, it's
    gonna be a maintenance nightmare. I'd just put the whole if () line in
    the #ifdef:

    #ifdef NO_JIM_CROW
    if (x <= 0)
    #else
    if (x < 0)
    #endif
    {

    (This being a rare case where I deviate from 1TBS, because if you put
    the { in both cases, it may confuse the editor.)

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Nov 4, 2009
    #2
    1. Advertising

  3. Phil Carmody <> writes:
    > I post this with minimal comment.
    >
    > Do not infer anything from the token names, you may pretend I named
    > them to mislead you etc. Please ignore whitespace wherever possible,
    > I just tabbed randomly.
    >
    > // ... includes, and all that jazz elided
    >
    > if (x
    > #ifdef EQUALITY_PERMITTED
    > <=
    > #else
    > <
    > #endif
    > UPPERBOUND) {
    > // kyrie elision
    > }
    >
    > Which circle of hell does the above reside in? For how many reasons
    > should the above be avoided? What could go wrong?


    The identifier EQUALITY_PERMITTED is reserved. (Presumably it's an
    error code indicating that quality is permitted.)

    Seebs posted a good suggestion. You might also consider
    a two-argument macro which is defined differently depending
    on whether EQUALITY_PERMITTED is defined or not:

    #ifdef IS_EQUALITY_PERMITTED
    #define FOO(x, y) ((x) <= (y))
    #else
    #define FOO(x, y) ((x) = (y))
    #endif

    The fact that I can't think of a good name for it probably says
    something significant about the whole idea.

    I presume the point is to conform to a coding standard that doesn't
    allow "==" comparisons for floating-point values. I can understand
    such a requirement, but IMHO it's silly to extend it to forbid "<=".
    (But if you need to conform to a silly coding standard, you gotta do
    what you gotta do.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 4, 2009
    #3
  4. Phil Carmody

    Phil Carmody Guest

    Keith Thompson <> writes:
    > Phil Carmody <> writes:
    >> I post this with minimal comment.
    >>
    >> Do not infer anything from the token names, you may pretend I named
    >> them to mislead you etc. Please ignore whitespace wherever possible,
    >> I just tabbed randomly.
    >>
    >> // ... includes, and all that jazz elided
    >>
    >> if (x
    >> #ifdef EQUALITY_PERMITTED
    >> <=
    >> #else
    >> <
    >> #endif
    >> UPPERBOUND) {
    >> // kyrie elision
    >> }
    >>
    >> Which circle of hell does the above reside in? For how many reasons
    >> should the above be avoided? What could go wrong?

    >
    > The identifier EQUALITY_PERMITTED is reserved. (Presumably it's an
    > error code indicating that quality is permitted.)


    12 bonus points for catching that uninteded one!

    > Seebs posted a good suggestion.


    Indeed.

    > You might also consider
    > a two-argument macro which is defined differently depending
    > on whether EQUALITY_PERMITTED is defined or not:
    >
    > #ifdef IS_EQUALITY_PERMITTED
    > #define FOO(x, y) ((x) <= (y))
    > #else
    > #define FOO(x, y) ((x) = (y))
    > #endif
    >
    > The fact that I can't think of a good name for it probably says
    > something significant about the whole idea.


    That might be what I'd chose instead, modulo names obviously.
    However, I openly admit to trusting modern compilers nowadays
    (and complain about the ones I don't trust), and I'd might even
    just use an inline function!

    > I presume the point is to conform to a coding standard that doesn't
    > allow "==" comparisons for floating-point values. I can understand
    > such a requirement, but IMHO it's silly to extend it to forbid "<=".
    > (But if you need to conform to a silly coding standard, you gotta do
    > what you gotta do.)


    An interesting hypothesis; I'm glad I said as little as I did, so
    that no restrictions were placed on what directions you could head
    down.

    I'll come clean now, and won't keep you in suspenders - it will make
    the place a bit stinkier though - let us hypothesise that someone
    made the following objection to the above construct:

    "don't do that, because if 'if()' is a macro, then you've got UB"

    (which is indeed true, according to para 10, IIRC).

    And for reference, I did not write either the code in question, or
    the objection, I am merely the archaeologist who recently dug them
    both up.

    Nose-clips on!
    Phil
    --
    Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
    Phil Carmody, Nov 4, 2009
    #4
  5. Phil Carmody <> writes:
    > Keith Thompson <> writes:
    >> Phil Carmody <> writes:
    >>> I post this with minimal comment.
    >>>
    >>> Do not infer anything from the token names, you may pretend I named
    >>> them to mislead you etc. Please ignore whitespace wherever possible,
    >>> I just tabbed randomly.
    >>>
    >>> // ... includes, and all that jazz elided
    >>>
    >>> if (x
    >>> #ifdef EQUALITY_PERMITTED
    >>> <=
    >>> #else
    >>> <
    >>> #endif
    >>> UPPERBOUND) {
    >>> // kyrie elision
    >>> }
    >>>
    >>> Which circle of hell does the above reside in? For how many reasons
    >>> should the above be avoided? What could go wrong?

    [snip]

    > I'll come clean now, and won't keep you in suspenders - it will make
    > the place a bit stinkier though - let us hypothesise that someone
    > made the following objection to the above construct:
    >
    > "don't do that, because if 'if()' is a macro, then you've got UB"
    >
    > (which is indeed true, according to para 10, IIRC).


    Well, first off, if if() is a macro, then someone should get a serious
    talking-to. But the only place I can find in the standard dealing
    with defining macros whose names are keywords is C99 7.1.2p5:

    The program shall not have any macros with names lexically
    identical to keywords currently defined prior to the inclusion.

    Assuming that if() is a function-like macro with one argument, and
    that it expands to something sane, I don't see a problem (other than
    extreme ugliness). It expands to either
    if (x <= UPPERBOUND)
    or
    if (x < UPPERBOUND)
    neither of which should be a problem assuming that if() is defined
    sanely (or as sanely as if() can be defined).

    What "para 10" are you referring to?

    > And for reference, I did not write either the code in question, or
    > the objection, I am merely the archaeologist who recently dug them
    > both up.


    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Nov 4, 2009
    #5
  6. Phil Carmody

    Phil Carmody Guest

    Keith Thompson <> writes:
    > Phil Carmody <> writes:
    >> Keith Thompson <> writes:
    >>> Phil Carmody <> writes:
    >>>> I post this with minimal comment.
    >>>>
    >>>> Do not infer anything from the token names, you may pretend I named
    >>>> them to mislead you etc. Please ignore whitespace wherever possible,
    >>>> I just tabbed randomly.
    >>>>
    >>>> // ... includes, and all that jazz elided
    >>>>
    >>>> if (x
    >>>> #ifdef EQUALITY_PERMITTED
    >>>> <=
    >>>> #else
    >>>> <
    >>>> #endif
    >>>> UPPERBOUND) {
    >>>> // kyrie elision
    >>>> }
    >>>>
    >>>> Which circle of hell does the above reside in? For how many reasons
    >>>> should the above be avoided? What could go wrong?

    > [snip]
    >
    >> I'll come clean now, and won't keep you in suspenders - it will make
    >> the place a bit stinkier though - let us hypothesise that someone
    >> made the following objection to the above construct:
    >>
    >> "don't do that, because if 'if()' is a macro, then you've got UB"
    >>
    >> (which is indeed true, according to para 10, IIRC).

    >
    > Well, first off, if if() is a macro, then someone should get a serious
    > talking-to. But the only place I can find in the standard dealing
    > with defining macros whose names are keywords is C99 7.1.2p5:
    >
    > The program shall not have any macros with names lexically
    > identical to keywords currently defined prior to the inclusion.
    >
    > Assuming that if() is a function-like macro with one argument, and
    > that it expands to something sane, I don't see a problem (other than
    > extreme ugliness). It expands to either
    > if (x <= UPPERBOUND)
    > or
    > if (x < UPPERBOUND)
    > neither of which should be a problem assuming that if() is defined
    > sanely (or as sanely as if() can be defined).
    >
    > What "para 10" are you referring to?


    Out-by-one error! I think this was being cited:

    6.10.3

    [#11] The sequence of preprocessing tokens bounded by the
    outside-most matching parentheses forms the list of
    arguments for the function-like macro. The individual
    arguments within the list are separated by comma
    preprocessing tokens, but comma preprocessing tokens between
    matching inner parentheses do not separate arguments. If
    there are sequences of preprocessing tokens within the list
    of arguments that would otherwise act as preprocessing
    directives, the behavior is undefined.

    Within the list? Hmmm, that doesn't apply, surely? The issue gets
    stickier...

    Phil
    --
    Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
    Phil Carmody, Nov 5, 2009
    #6
  7. Phil Carmody

    Noob Guest

    Phil Carmody wrote:

    > I post this with minimal comment.
    >
    > Do not infer anything from the token names, you may pretend I named
    > them to mislead you etc. Please ignore whitespace wherever possible,
    > I just tabbed randomly.
    >
    > // ... includes, and all that jazz elided
    >
    > if (x
    > #ifdef EQUALITY_PERMITTED
    > <=
    > #else
    > <
    > #endif
    > UPPERBOUND) {
    > // kyrie elision
    > }


    Would having a conditional definition for the relational operator be any
    improvement?

    #ifdef EQUALITY_PERMITTED
    #define LESS_THAN <=
    #else
    #define LESS_THAN <
    #endif

    if (x LESS_THAN UPPERBOUND) {
    ...
    }
    Noob, Nov 5, 2009
    #7
  8. On Thu, 05 Nov 2009 11:25:27 +0100, Noob <root@127.0.0.1> wrote:

    >Phil Carmody wrote:
    >
    >> I post this with minimal comment.
    >>
    >> Do not infer anything from the token names, you may pretend I named
    >> them to mislead you etc. Please ignore whitespace wherever possible,
    >> I just tabbed randomly.
    >>
    >> // ... includes, and all that jazz elided
    >>
    >> if (x
    >> #ifdef EQUALITY_PERMITTED
    >> <=
    >> #else
    >> <
    >> #endif
    >> UPPERBOUND) {
    >> // kyrie elision
    >> }

    >
    >Would having a conditional definition for the relational operator be any
    >improvement?
    >
    >#ifdef EQUALITY_PERMITTED
    >#define LESS_THAN <=
    >#else
    >#define LESS_THAN <
    >#endif
    >
    > if (x LESS_THAN UPPERBOUND) {
    > ...
    > }


    How can potentially misleading someone who reads the code later be an
    improvement?

    --
    Remove del for email
    Barry Schwarz, Nov 6, 2009
    #8
  9. Phil Carmody

    Seebs Guest

    On 2009-11-06, Barry Schwarz <> wrote:
    > How can potentially misleading someone who reads the code later be an
    > improvement?


    I'd guess that the macro would be a pretty big hint that "LESS_THAN" might
    be more complicated than "<", but you do have a point.

    One way might be that it's april first and you have to submit the material
    for code review. Then you're making a coworker smile!

    -s
    --
    Copyright 2009, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    Seebs, Nov 6, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Clare Hsiao
    Replies:
    0
    Views:
    327
    Clare Hsiao
    Feb 12, 2004
  2. Tom
    Replies:
    3
    Views:
    421
    Jeffrey Palermo [MCP]
    Dec 1, 2004
  3. Edwin Knoppert
    Replies:
    0
    Views:
    370
    Edwin Knoppert
    Nov 30, 2005
  4. Gil Blais
    Replies:
    0
    Views:
    368
    Gil Blais
    Apr 15, 2004
  5. Gil Blais
    Replies:
    12
    Views:
    820
    Hemal Pandya
    Jul 15, 2004
Loading...

Share This Page