Can A Macro Do This?

G

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
 
S

santosh

gamename said:
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);
 
S

santosh

jacob said:
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.
 
J

jacob navia

santosh said:
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???
That can't be right!
 
S

santosh

jacob said:
Yes but now that I think about it...

How can foo be 3 different things at the same time as in the
original code???

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.
 
G

gamename

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.
 
B

Björn Paetzel

santosh said:
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);

/* ;) */
 
C

CBFalconer

jacob said:
.... 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???


That can't be right!

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

Now it passes the assert :)
 
F

Francine.Neary

Yes but now that I think about it...

How can foo be 3 different things at the same time as in the
original code???

That can't be right!

Perhaps foo is a macro with side-effects?
 
J

jacob navia

CBFalconer said:
#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!
 
P

Peter Nilsson

gamename said:
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);
 
B

Ben Pfaff

Someone said:
assert(foo==X);
assert(foo==Y);
assert(foo==Z);

CBFalconer said:
#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 }).
 
B

Barry Schwarz

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
 
P

Philip Potter

Barry said:
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.
 
P

pete

Philip said:
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 */
 
B

Barry Schwarz

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
 
P

Philip Potter

Barry said:
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.
 
P

Philip Potter

Philip said:
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.
 
E

Eberhard Schefold

jacob said:
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.
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top