Can A Macro Do This?

[gamename]

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

[jacob navia]

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

[Peter Nilsson]

gamename <[e-mail] mwrote:

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

[Ben Pfaff]

Someone wrote:

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

CBFalconer <cb********@yah oo.comwrites:

#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);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,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)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Barry Schwarz]

On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
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

[Philip Potter]

Barry Schwarz wrote:

On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
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.

[pete]

Philip Potter wrote:

>
Barry Schwarz wrote:

On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
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

[Barry Schwarz]

On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>Barry Schwarz wrote:

>On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
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
expression s 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

[Philip Potter]

Barry Schwarz wrote:

On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>Barry Schwarz wrote:

>>On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
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
expressio ns 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]

Philip Potter wrote:

Barry Schwarz wrote:

>On Fri, 30 Nov 2007 12:54:04 +0000, Philip Potter <pg*@doc.ic.ac. uk>
wrote:

>>Barry Schwarz wrote:
On Wed, 28 Nov 2007 16:45:40 +0100, Björn Paetzel <ne**@kolrabi.d e>
wrote:

santosh schrieb:
>
>>How can foo be 3 different things at the same time as in the
>>origina l 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
>expression s 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.

[Eberhard Schefold]

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.