Use of Assertions

[Divick]

Hi,
is it a nice idea to do assetion checks for method arguments ? I
am currently redesigning a piece of code. Now the problem is that there
are some assumptions for the method arguments that the code makes. It
is not checking the validity of the arguments everywhere because that
would lead to performance penalty. So I am think that at least
assertions will be able check the arguments at least for debug version
to verify the design. But now it means that I put the assertions
everywhere in the code, something like below:

Code with out checks

func1(Ptr1 * ptr1, Ptr2 * ptr2)
{
ptr2->do something...
ptr1->call some method(ptr2);
}

Code with assertions
func1(Ptr1 * ptr1, Ptr2 * ptr2)
{
assert( ptr1!= NULL && ptr2 != NULL); // And do this for all
functions with arguments everywhere
ptr2->do something...
ptr1->call some method(ptr2);
}

so my questions really is : Is it a good idea to put the assertions for
the function arguments like shown above? Why or why not?

Thanks,
Divick

[Gianni Mariani]

Divick wrote:

Hi,
is it a nice idea to do assetion checks for method arguments ? I
YES.

.... }

Code with assertions
func1(Ptr1 * ptr1, Ptr2 * ptr2)
{
assert( ptr1!= NULL && ptr2 != NULL); // And do this for all
assert( ptr1 )
assert( ptr2 )

Validate *each* argument rather than have one long expression.

NULL *is* 0 is C++. I don't use NULL any more (personal preference).

functions with arguments everywhere
ptr2->do something...
ptr1->call some method(ptr2);
}

so my questions really is : Is it a good idea to put the assertions for
the function arguments like shown above? Why or why not?

It's a good idea because:

a) It documents your assumptions and enforces them (at least in debug).
b) It catches errors early (which is always desirable).

[Alf P. Steinbach]

* Divick:

Hi,
is it a nice idea to do assetion checks for method arguments ? I
am currently redesigning a piece of code. Now the problem is that there
are some assumptions for the method arguments that the code makes. It
is not checking the validity of the arguments everywhere because that
would lead to performance penalty. So I am think that at least
assertions will be able check the arguments at least for debug version
to verify the design. But now it means that I put the assertions
everywhere in the code, something like below:

Code with out checks

func1(Ptr1 * ptr1, Ptr2 * ptr2)
{
ptr2->do something...
ptr1->call some method(ptr2);
}

Code with assertions
func1(Ptr1 * ptr1, Ptr2 * ptr2)
{
assert( ptr1!= NULL && ptr2 != NULL); // And do this for all
functions with arguments everywhere
ptr2->do something...
ptr1->call some method(ptr2);
}

so my questions really is : Is it a good idea to put the assertions for
the function arguments like shown above?
No.

Why or why not?

Use reference arguments where you don't intend to support NULL-values.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Ben Pope]

Divick wrote:

Hi,
is it a nice idea to do assetion checks for method arguments ? I
am currently redesigning a piece of code. Now the problem is that there
are some assumptions for the method arguments that the code makes. It
is not checking the validity of the arguments everywhere because that
would lead to performance penalty.

1st priority: Correctness.
2nd priority: Correctness!

Much lower priority: Performance.

Always validate the arguments, if there IS a performance penalty convert
the ones that matter to assertions.

If the input comes from the user, or a file or something, then
assertions are not really a suitable option. Validate those things ASAP
to contain the problem.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...

[Divick]

>>Use reference arguments where you don't intend to support NULL-values.
Could you please give an example?

Seems like people have different opinions about this. Confused...:(

Divick

[Jurko Gospodnetic]

Hi Divick

Use reference arguments where you don't intend to support NULL-values.

Could you please give an example?

Seems like people have different opinions about this. Confused...:(

I do not think many people have different opinions on this. :-)

Those who said that you should use assertions to make sure
your pointer parameters are not 0 were assuming you had a
reason for using pointers in the first place. What Alf said was
that you the question of whether to use assertions for this should
not be an issue if you do not need pointers here but can use
references.

In other words....
1. use assertions where needed.
2. use references instead of pointers wherever possible.

Just my two cents worth... and I hope it helps...

Best regards,
Jurko Gospodnetic

[Divick]

>>Those who said that you should use assertions to make sure

your pointer parameters are not 0 were assuming you had a
reason for using pointers in the first place. What Alf said was
that you the question of whether to use assertions for this should
not be an issue if you do not need pointers here but can use
references.

Ok, that helps. Now I understand what Alf was trying to say.

Thanks a lot,
Divick

[Jacek Dziedzic]

Gianni Mariani wrote:

NULL *is* 0 is C++. I don't use NULL any more (personal preference).

Yes, but what about problems like that which was discussed
recently:

http://groups.google.com/group/comp....93d210e3c2b5cb

- J.

[Jacek Dziedzic]

Divick wrote:

Hi,
is it a nice idea to do assetion checks for method arguments ?

Yes! Better safe than sorry.

If you are worried about performance (better support this
with an actual time-test, rather than thinking "this could
be too slow"), you might have two styles of asserts, like

Assert(...)
and
CostlyAssert(.. .)

that would be turned on/off independently with preprocessor
stuff like

#define WANT_ASSERTS
#define WANT_COSTLYASSE RTS

Then you could leave Asserts on for both debug and release
versions and turn CostlyAsserts only for debugging.

HTH,
- J.

[Gianni Mariani]

Jacek Dziedzic wrote:

Gianni Mariani wrote:

NULL *is* 0 is C++. I don't use NULL any more (personal preference).

Yes, but what about problems like that which was discussed
recently:

http://groups.google.com/group/comp....93d210e3c2b5cb

That's a gem.

Yes, function overloading with templates and the special meaning of
literal 0 gets "overloaded ".

It's too late now, but I think the language rules around the 0 literal
and null pointers to now be a bad idea. The NULL macro provides no help
here from a readability perspective, so I think that's a bad idea as
well (IMHO).