"Safer" assert?

J

Joseph Turian

I've been using assert liberally throughout my code.
Then, upon compiling with -NDEBUG, I found that my program had
different output.
Why? Because -NDEBUG disables assert, but I had (at least) one assert
with a side-effect.

Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?

Thanks,
Joseph
 
G

Gavin Deane

Joseph said:
I've been using assert liberally throughout my code.
Then, upon compiling with -NDEBUG, I found that my program had
different output.
Why? Because -NDEBUG disables assert, but I had (at least) one assert
with a side-effect.

It's not a good idea for an assert to have a side-effect that affects
the behaviour of your program for precisely the reason you have
discovered.

Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?

Can you show some example code that illustrates what you are trying to
do?

Gavin Deane
 
F

Frederick Gotham

Joseph Turian:
I've been using assert liberally throughout my code.

Brilliant.


Then, upon compiling with -NDEBUG, I found that my program had
different output.
Why? Because -NDEBUG disables assert, but I had (at least) one assert
with a side-effect.

Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?


First of all, there's nothing wrong with "assert". The only problem is your
malusage of it.

Here's a quick idea to find the asserts which have side-effects.

Firstly, make a copy of the entire project, i.e. all the code files. Do a
"Find and Replace", replacing each occurence of "assert" with "assertBAD".
Compile the program and you should get a list of lines on which the
unidentified identifier "assertBAD" was used. Save the compiler output to a
text file (i.e. the file and line number errors).

Now, use your compiler options to define the following macro across the
entire program:

#define assertBAD(expr) expr

Now, re-compile the program. If you have the appropriate warning level set,
the compiler will warn you of any redundant expression-statements. Here's
an example of a Before and After:

Before:

int main()
{
assert(i % 10);
}

After:

int main()
{
i % 10;
}

The compiler can see plainly that the expression-statement is useless, and
will warn you. Again, save the compiler output to a file.

Now compare the two lists. The ones that are on the first list but which
aren't on the second are the ones which have side-effects. Of course you'll
get a few false-positives such as:

UserDefinedType obj;

assert(obj.IsOpen());

, but hopefully they'll be in the minority.
 
N

Noah Roberts

Joseph said:
I've been using assert liberally throughout my code.
Then, upon compiling with -NDEBUG, I found that my program had
different output.
Why? Because -NDEBUG disables assert, but I had (at least) one assert
with a side-effect.

Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?

No. Nothing you can do will keep you from shooting yourself in the
head in this manner. Anything that could be remotely considered could
be worked around since even a const call on a const object could have
side effects.
 
A

Andrey Tarasevich

Joseph said:
...
Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?
...

Assertion with side effect is not something unusual, as long as this
side effect is only needed in the DEBUG version of the program (i.e. is
there for the sole purpose of supporting this and other assertions).
'assert', of course, does not and cannot know whether each specific side
effect is critical to the correct behavior of the NDEBUG version. I
don't think it is possible to implement a side-effect-aware version of
'assert' without a dedicated support from the compiler.
 
M

Marcus Kwok

Joseph Turian said:
I've been using assert liberally throughout my code.
Then, upon compiling with -NDEBUG, I found that my program had
different output.
Why? Because -NDEBUG disables assert, but I had (at least) one assert
with a side-effect.

Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?

Well, on comp.lang.c++.moderated there was this (somewhat lengthy)
thread a little bit ago about the VERIFY(expr) macro, which is intended
to act like assert(expr) in debug mode, but still evaluates expr in
release mode.

http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/85b034283152115e/
 
?

=?ISO-8859-15?Q?Juli=E1n?= Albo

Joseph said:
I've been using assert liberally throughout my code.
Then, upon compiling with -NDEBUG, I found that my program had
different output.
Why? Because -NDEBUG disables assert, but I had (at least) one assert
with a side-effect.
Can someone recommend a safer mechanism for assertions? e.g. one that
determines the const-ness of what is being checked?

I think assert has accomplished his goal in this case, you have found a bug,
it isn't?
 

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,769
Messages
2,569,580
Members
45,054
Latest member
TrimKetoBoost

Latest Threads

Top