Can A Macro Do This?

Discussion in 'C Programming' started by gamename, Nov 28, 2007.

  1. gamename

    gamename Guest

    Hi

    Right now I do multiple asserts to verify multiple values:
    assert(foo==X);
    assert(foo==Y);
    assert(foo==Z);

    Is there any way to macro-ize this and do it in one call?
    MYASRT(foo, (X||Y||Z));
    ... or maybe...
    MYASRT(foo,OR,X,Y,Z));

    TIA,
    -T
     
    gamename, Nov 28, 2007
    #1
    1. Advertising

  2. gamename

    santosh Guest

    gamename wrote:

    > Hi
    >
    > Right now I do multiple asserts to verify multiple values:
    > assert(foo==X);
    > assert(foo==Y);
    > assert(foo==Z);
    >
    > Is there any way to macro-ize this and do it in one call?
    > MYASRT(foo, (X||Y||Z));
    > ... or maybe...
    > MYASRT(foo,OR,X,Y,Z));


    What's wrong with:

    assert(foo == X || foo == Y || foo == Z);
     
    santosh, Nov 28, 2007
    #2
    1. Advertising

  3. gamename

    jacob navia Guest

    santosh wrote:
    > gamename wrote:
    >
    >> Hi
    >>
    >> Right now I do multiple asserts to verify multiple values:
    >> assert(foo==X);
    >> assert(foo==Y);
    >> assert(foo==Z);
    >>
    >> Is there any way to macro-ize this and do it in one call?
    >> MYASRT(foo, (X||Y||Z));
    >> ... or maybe...
    >> MYASRT(foo,OR,X,Y,Z));

    >
    > What's wrong with:
    >
    > assert(foo == X || foo == Y || foo == Z);
    >
    >


    That is wrong!
    Should be:


    assert(foo == X && foo == Y && foo == Z);


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Nov 28, 2007
    #3
  4. gamename

    santosh Guest

    jacob navia wrote:

    > santosh wrote:
    >> gamename wrote:
    >>
    >>> Hi
    >>>
    >>> Right now I do multiple asserts to verify multiple values:
    >>> assert(foo==X);
    >>> assert(foo==Y);
    >>> assert(foo==Z);
    >>>
    >>> Is there any way to macro-ize this and do it in one call?
    >>> MYASRT(foo, (X||Y||Z));
    >>> ... or maybe...
    >>> MYASRT(foo,OR,X,Y,Z));

    >>
    >> What's wrong with:
    >>
    >> assert(foo == X || foo == Y || foo == Z);
    >>
    >>

    >
    > That is wrong!
    > Should be:
    >
    >
    > assert(foo == X && foo == Y && foo == Z);


    Oops yes. You are right.

    In my defence I got sidetracked by the "MYASRT" macro presented by the
    OP, where he uses the OR operator, instead of the AND.
     
    santosh, Nov 28, 2007
    #4
  5. gamename

    jacob navia Guest

    santosh wrote:
    > jacob navia wrote:
    >
    >> santosh wrote:
    >>> gamename wrote:
    >>>
    >>>> Hi
    >>>>
    >>>> Right now I do multiple asserts to verify multiple values:
    >>>> assert(foo==X);
    >>>> assert(foo==Y);
    >>>> assert(foo==Z);
    >>>>
    >>>> Is there any way to macro-ize this and do it in one call?
    >>>> MYASRT(foo, (X||Y||Z));
    >>>> ... or maybe...
    >>>> MYASRT(foo,OR,X,Y,Z));
    >>> What's wrong with:
    >>>
    >>> assert(foo == X || foo == Y || foo == Z);
    >>>
    >>>

    >> That is wrong!
    >> Should be:
    >>
    >>
    >> assert(foo == X && foo == Y && foo == Z);

    >
    > Oops yes. You are right.
    >
    > In my defence I got sidetracked by the "MYASRT" macro presented by the
    > OP, where he uses the OR operator, instead of the AND.
    >


    Yes but now that I think about it...

    How can foo be 3 different things at the same time as in the
    original code???
    >>>> assert(foo==X);
    >>>> assert(foo==Y);
    >>>> assert(foo==Z);


    That can't be right!


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Nov 28, 2007
    #5
  6. gamename

    santosh Guest

    jacob navia wrote:

    > santosh wrote:
    >> jacob navia wrote:
    >>
    >>> santosh wrote:
    >>>> gamename wrote:
    >>>>
    >>>>> Hi
    >>>>>
    >>>>> Right now I do multiple asserts to verify multiple values:
    >>>>> assert(foo==X);
    >>>>> assert(foo==Y);
    >>>>> assert(foo==Z);
    >>>>>
    >>>>> Is there any way to macro-ize this and do it in one call?
    >>>>> MYASRT(foo, (X||Y||Z));
    >>>>> ... or maybe...
    >>>>> MYASRT(foo,OR,X,Y,Z));
    >>>> What's wrong with:
    >>>>
    >>>> assert(foo == X || foo == Y || foo == Z);
    >>>>
    >>>>
    >>> That is wrong!
    >>> Should be:
    >>>
    >>>
    >>> assert(foo == X && foo == Y && foo == Z);

    >>
    >> Oops yes. You are right.
    >>
    >> In my defence I got sidetracked by the "MYASRT" macro presented by
    >> the OP, where he uses the OR operator, instead of the AND.
    >>

    >
    > Yes but now that I think about it...
    >
    > How can foo be 3 different things at the same time as in the
    > original code???
    > >>>> assert(foo==X);
    > >>>> assert(foo==Y);
    > >>>> assert(foo==Z);

    >
    > That can't be right!


    Yes. The sequence of assert invocations as presented seem redundant. Of
    course some code could occur between the calls or the OP might have
    just presented this as an example to enquire about writing complex
    expressions with assert.
     
    santosh, Nov 28, 2007
    #6
  7. gamename

    gamename Guest

    > Yes. The sequence of assert invocations as presented seem redundant. Of
    > course some code could occur between the calls or the OP might have
    > just presented this as an example to enquire about writing complex
    > expressions with assert.


    Correct. The example is simplified for that purpose.
     
    gamename, Nov 28, 2007
    #7
  8. santosh schrieb:

    >> How can foo be 3 different things at the same time as in the
    >> original code???
    >> >>>> assert(foo==X);
    >> >>>> assert(foo==Y);
    >> >>>> assert(foo==Z);

    >>
    >> That can't be right!

    >
    > Yes. The sequence of assert invocations as presented seem redundant. Of
    > course some code could occur between the calls or the OP might have
    > just presented this as an example to enquire about writing complex
    > expressions with assert.


    Maybe he wanted to something like this:

    assert(foo==X==Y==Z);

    /* ;) */

    --
    OMG,-10==10 in linux!
     
    Björn Paetzel, Nov 28, 2007
    #8
  9. gamename

    CBFalconer Guest

    jacob navia wrote:
    > santosh wrote:
    >> jacob navia wrote:
    >>

    .... snip ...
    >>>
    >>> assert(foo == X && foo == Y && foo == Z);

    >>

    .... snip ...
    >
    > Yes but now that I think about it...
    >
    > How can foo be 3 different things at the same time as in the
    > original code???
    >
    >>>>> assert(foo==X);
    >>>>> assert(foo==Y);
    >>>>> assert(foo==Z);

    >
    > That can't be right!


    #define foo n++
    #enum {X, Y, Z);
    int n = 0;

    Now it passes the assert :)

    --
    Chuck F (cbfalconer at maineline dot net)
    <http://cbfalconer.home.att.net>
    Try the download section.


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    CBFalconer, Nov 28, 2007
    #9
  10. gamename

    Guest

    On Nov 28, 3:17 pm, jacob navia <> wrote:
    > santosh wrote:
    > > jacob navia wrote:

    >
    > >> santosh wrote:
    > >>> gamename wrote:

    >
    > >>>> Hi

    >
    > >>>> Right now I do multiple asserts to verify multiple values:
    > >>>> assert(foo==X);
    > >>>> assert(foo==Y);
    > >>>> assert(foo==Z);

    >
    > >>>> Is there any way to macro-ize this and do it in one call?
    > >>>> MYASRT(foo, (X||Y||Z));
    > >>>> ... or maybe...
    > >>>> MYASRT(foo,OR,X,Y,Z));
    > >>> What's wrong with:

    >
    > >>> assert(foo == X || foo == Y || foo == Z);

    >
    > >> That is wrong!
    > >> Should be:

    >
    > >> assert(foo == X && foo == Y && foo == Z);

    >
    > > Oops yes. You are right.

    >
    > > In my defence I got sidetracked by the "MYASRT" macro presented by the
    > > OP, where he uses the OR operator, instead of the AND.

    >
    > Yes but now that I think about it...
    >
    > How can foo be 3 different things at the same time as in the
    > original code???
    > >>>> assert(foo==X);
    > >>>> assert(foo==Y);
    > >>>> assert(foo==Z);

    >
    > That can't be right!


    Perhaps foo is a macro with side-effects?

    >
    > --
    > jacob navia
    > jacob at jacob point remcomp point fr
    > logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32
     
    , Nov 28, 2007
    #10
  11. gamename

    jacob navia Guest

    CBFalconer wrote:
    > jacob navia wrote:
    >> santosh wrote:
    >>> jacob navia wrote:
    >>>

    > ... snip ...
    >>>> assert(foo == X && foo == Y && foo == Z);

    > ... snip ...
    >> Yes but now that I think about it...
    >>
    >> How can foo be 3 different things at the same time as in the
    >> original code???
    >>
    >>>>>> assert(foo==X);
    >>>>>> assert(foo==Y);
    >>>>>> assert(foo==Z);

    >> That can't be right!

    >
    > #define foo n++
    > #enum {X, Y, Z);
    > int n = 0;
    >
    > Now it passes the assert :)
    >


    A macro with side effects within an
    assert() expression.

    That is *really* a bad programming style. Yes
    everything is possible but *that* would be an abomination,
    and a useless one, since the assert macro would NOT
    increment the "counter" if NDEBUG was defined!


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Nov 28, 2007
    #11
  12. gamename <> wrote:
    > Hi
    >
    > Right now I do multiple asserts to verify multiple values:
    > assert(foo==X);
    > assert(foo==Y);
    > assert(foo==Z);
    >
    > Is there any way to macro-ize this and do it in one call?
    > MYASRT(foo, (X||Y||Z));
    > ... or maybe...
    > MYASRT(foo,OR,X,Y,Z));


    assert(foo == X || foo == Y || foo == Z);

    --
    Peter
     
    Peter Nilsson, Nov 28, 2007
    #12
  13. gamename

    Ben Pfaff Guest

    Someone wrote:
    > assert(foo==X);
    > assert(foo==Y);
    > assert(foo==Z);


    CBFalconer <> writes:
    > #define foo n++
    > #enum {X, Y, Z);
    > int n = 0;
    >
    > Now it passes the assert :)


    Is assert guaranteed to evaluate its argument only once (without
    NDEBUG)?

    (Also, enum is not a preprocessor directive, and its list of
    enumeration values ends in }).
    --
    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;}}}
     
    Ben Pfaff, Nov 29, 2007
    #13
  14. On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <>
    wrote:

    >santosh schrieb:
    >
    >>> How can foo be 3 different things at the same time as in the
    >>> original code???
    >>> >>>> assert(foo==X);
    >>> >>>> assert(foo==Y);
    >>> >>>> assert(foo==Z);
    >>>
    >>> That can't be right!

    >>
    >> Yes. The sequence of assert invocations as presented seem redundant. Of
    >> course some code could occur between the calls or the OP might have
    >> just presented this as an example to enquire about writing complex
    >> expressions with assert.

    >
    >Maybe he wanted to something like this:
    >
    >assert(foo==X==Y==Z);
    >
    >/* ;) */


    Since == is not transitive in the same sense = is, it seems unlikely.


    Remove del for email
     
    Barry Schwarz, Nov 30, 2007
    #14
  15. Barry Schwarz wrote:
    > On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <>
    > wrote:
    >
    >> santosh schrieb:
    >>
    >>>> How can foo be 3 different things at the same time as in the
    >>>> original code???
    >>>> >>>> assert(foo==X);
    >>>> >>>> assert(foo==Y);
    >>>> >>>> assert(foo==Z);
    >>>>
    >>>> That can't be right!
    >>> Yes. The sequence of assert invocations as presented seem redundant. Of
    >>> course some code could occur between the calls or the OP might have
    >>> just presented this as an example to enquire about writing complex
    >>> expressions with assert.

    >> Maybe he wanted to something like this:
    >>
    >> assert(foo==X==Y==Z);
    >>
    >> /* ;) */

    >
    > Since == is not transitive in the same sense = is, it seems unlikely.


    A relation R is transitive if a R b && b R c implies a R c for all
    a,b,c. I believe this applies to == and it's even appropriate for =
    because it isn't a relation.
     
    Philip Potter, Nov 30, 2007
    #15
  16. gamename

    pete Guest

    Philip Potter wrote:
    >
    > Barry Schwarz wrote:
    > > On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <>
    > > wrote:
    > >
    > >> santosh schrieb:
    > >>
    > >>>> How can foo be 3 different things at the same time as in the
    > >>>> original code???
    > >>>> >>>> assert(foo==X);
    > >>>> >>>> assert(foo==Y);
    > >>>> >>>> assert(foo==Z);
    > >>>>
    > >>>> That can't be right!
    > >>> Yes. The sequence of assert invocations as presented seem redundant. Of
    > >>> course some code could occur between the calls or the OP might have
    > >>> just presented this as an example to enquire about writing complex
    > >>> expressions with assert.
    > >> Maybe he wanted to something like this:
    > >>
    > >> assert(foo==X==Y==Z);
    > >>
    > >> /* ;) */

    > >
    > > Since == is not transitive in the same sense = is, it seems unlikely.

    >
    > A relation R is transitive if a R b && b R c implies a R c for all
    > a,b,c. I believe this applies to == and it's even appropriate for =
    > because it isn't a relation.


    (NULL == 0) /* defined */
    ( 0.0 == 0) /* defined */
    (NULL == 0.0) /* undefined */

    --
    pete
     
    pete, Dec 1, 2007
    #16
  17. On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <>
    wrote:

    >Barry Schwarz wrote:
    >> On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <>
    >> wrote:
    >>
    >>> santosh schrieb:
    >>>
    >>>>> How can foo be 3 different things at the same time as in the
    >>>>> original code???
    >>>>> >>>> assert(foo==X);
    >>>>> >>>> assert(foo==Y);
    >>>>> >>>> assert(foo==Z);
    >>>>>
    >>>>> That can't be right!
    >>>> Yes. The sequence of assert invocations as presented seem redundant. Of
    >>>> course some code could occur between the calls or the OP might have
    >>>> just presented this as an example to enquire about writing complex
    >>>> expressions with assert.
    >>> Maybe he wanted to something like this:
    >>>
    >>> assert(foo==X==Y==Z);
    >>>
    >>> /* ;) */

    >>
    >> Since == is not transitive in the same sense = is, it seems unlikely.

    >
    >A relation R is transitive if a R b && b R c implies a R c for all
    >a,b,c. I believe this applies to == and it's even appropriate for =
    >because it isn't a relation.


    Equality is transitive. The == operator is not.

    Due to left to right associativity, the expression foo == X == Y == Z
    is parsed as (((foo == X) == Y) == Z). The innermost expression must
    evaluate to 0 or 1. If all four variables have the value 5, the
    intuitive meaning of the expression should be TRUE but foo == X
    evaluates to 1, 1 == Y evaluates to 0, and 0 == Z evaluates to 0 and
    the expression is FALSE. Even if associativity were reversed, the
    expression would still evaluate to FALSE.


    Remove del for email
     
    Barry Schwarz, Dec 2, 2007
    #17
  18. Barry Schwarz wrote:
    > On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <>
    > wrote:
    >
    >> Barry Schwarz wrote:
    >>> On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <>
    >>> wrote:
    >>>
    >>>> santosh schrieb:
    >>>>
    >>>>>> How can foo be 3 different things at the same time as in the
    >>>>>> original code???
    >>>>>> >>>> assert(foo==X);
    >>>>>> >>>> assert(foo==Y);
    >>>>>> >>>> assert(foo==Z);
    >>>>>>
    >>>>>> That can't be right!
    >>>>> Yes. The sequence of assert invocations as presented seem redundant. Of
    >>>>> course some code could occur between the calls or the OP might have
    >>>>> just presented this as an example to enquire about writing complex
    >>>>> expressions with assert.
    >>>> Maybe he wanted to something like this:
    >>>>
    >>>> assert(foo==X==Y==Z);
    >>>>
    >>>> /* ;) */
    >>> Since == is not transitive in the same sense = is, it seems unlikely.

    >> A relation R is transitive if a R b && b R c implies a R c for all
    >> a,b,c. I believe this applies to == and it's even appropriate for =
    >> because it isn't a relation.

    >
    > Equality is transitive. The == operator is not.
    >
    > Due to left to right associativity, the expression foo == X == Y == Z
    > is parsed as (((foo == X) == Y) == Z). The innermost expression must
    > evaluate to 0 or 1. If all four variables have the value 5, the
    > intuitive meaning of the expression should be TRUE but foo == X
    > evaluates to 1, 1 == Y evaluates to 0, and 0 == Z evaluates to 0 and
    > the expression is FALSE. Even if associativity were reversed, the
    > expression would still evaluate to FALSE.


    You appear to have ignored my definition of transitivity.

    If knowing that a == b && b == c means that you know for sure that a ==
    c, then == is transitive. It has nothing to do with being able to use
    the a == b == c syntax. As I said, I believe that == is transitive, but
    I don't know the standard well enough to confirm this.
     
    Philip Potter, Dec 3, 2007
    #18
  19. Philip Potter wrote:
    > Barry Schwarz wrote:
    >> On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <>
    >> wrote:
    >>
    >>> Barry Schwarz wrote:
    >>>> On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <>
    >>>> wrote:
    >>>>
    >>>>> santosh schrieb:
    >>>>>
    >>>>>>> How can foo be 3 different things at the same time as in the
    >>>>>>> original code???
    >>>>>>> >>>> assert(foo==X);
    >>>>>>> >>>> assert(foo==Y);
    >>>>>>> >>>> assert(foo==Z);
    >>>>>>>
    >>>>>>> That can't be right!
    >>>>>> Yes. The sequence of assert invocations as presented seem redundant. Of
    >>>>>> course some code could occur between the calls or the OP might have
    >>>>>> just presented this as an example to enquire about writing complex
    >>>>>> expressions with assert.
    >>>>> Maybe he wanted to something like this:
    >>>>>
    >>>>> assert(foo==X==Y==Z);
    >>>>>
    >>>>> /* ;) */
    >>>> Since == is not transitive in the same sense = is, it seems unlikely.
    >>> A relation R is transitive if a R b && b R c implies a R c for all
    >>> a,b,c. I believe this applies to == and it's even appropriate for =
    >>> because it isn't a relation.

    >> Equality is transitive. The == operator is not.
    >>
    >> Due to left to right associativity, the expression foo == X == Y == Z
    >> is parsed as (((foo == X) == Y) == Z). The innermost expression must
    >> evaluate to 0 or 1. If all four variables have the value 5, the
    >> intuitive meaning of the expression should be TRUE but foo == X
    >> evaluates to 1, 1 == Y evaluates to 0, and 0 == Z evaluates to 0 and
    >> the expression is FALSE. Even if associativity were reversed, the
    >> expression would still evaluate to FALSE.

    >
    > You appear to have ignored my definition of transitivity.
    >
    > If knowing that a == b && b == c means that you know for sure that a ==
    > c, then == is transitive. It has nothing to do with being able to use
    > the a == b == c syntax. As I said, I believe that == is transitive, but
    > I don't know the standard well enough to confirm this.


    Hmm, for a = (int *) 0, b = 0, c = (float *) 0:

    a == b && b == c, but a == c is a constraint violation. I think. So ==
    is not transitive in the mathematical sense.
     
    Philip Potter, Dec 3, 2007
    #19
  20. jacob navia wrote:

    >> Now it passes the assert :)
    >>

    >
    > A macro with side effects within an
    > assert() expression.
    >
    > That is *really* a bad programming style. Yes
    > everything is possible but *that* would be an abomination,
    > and a useless one, since the assert macro would NOT
    > increment the "counter" if NDEBUG was defined!


    I believe you missed the smiley.
     
    Eberhard Schefold, Dec 3, 2007
    #20
    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. Dead RAM
    Replies:
    20
    Views:
    1,118
    John Harrison
    Jul 14, 2004
  2. D Senthil Kumar

    macro name from macro?

    D Senthil Kumar, Sep 20, 2003, in forum: C Programming
    Replies:
    1
    Views:
    582
    Jack Klein
    Sep 21, 2003
  3. sounak

    to get macro name from macro value

    sounak, Nov 22, 2005, in forum: C Programming
    Replies:
    17
    Views:
    504
    Mark McIntyre
    Nov 22, 2005
  4. Patrick Kowalzick
    Replies:
    5
    Views:
    477
    Patrick Kowalzick
    Mar 14, 2006
  5. Mike Manilone

    macro inside macro

    Mike Manilone, Oct 3, 2011, in forum: C Programming
    Replies:
    8
    Views:
    462
    Mike Manilone
    Oct 6, 2011
Loading...

Share This Page