Archived

This topic is now archived and is closed to further replies.

Assertions??

This topic is 5649 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Can somebody give me some help with "assertions" and when and why to use them? I have been building my engine for quite some time now and need to know whether having these assertion handling is good. (Almost all free source engines handle run time or compiler assertions or both). I do not understand exactly why we would need to use them. If you are not making mistakes while programming why would you need to check to see if you are making mistakes? (I am assuming that an assertion will simply check the type of an object to insure it is the correct type/size/bounds..) This all sounds like unnecessary work and wasted time.. Also, if anyone happens to know the bit of code that allows you to output to the watch window of VC++6.0 in debug mode let me know! Thanks a ton! Regards,

Share this post


Link to post
Share on other sites
Assertions are statements reflecting assumptions your code makes. An example of a compile-time assertion would be:

template <class T>
class Test {
typedef T type_must_be_complete[1];
};

If you try to just declare a type, say

class SomeType;

and then use it as a template parameter, the above typedef will not compile:

Test <SomeType> t;

In order for the typedef to compile, T''s size must be known, which means that T must be defined, not just declared, when an object of type Test is instantiated.

--

Run-time assertions reflect similar assumptions at runtime. For example, the classic assertion is that index passed to overloaded operator [] for arrays is within bounds:

T& operator [](int index) {
ASSERT(index >= 0 && index < size());
...
}

If you''re compiling in debug mode, ASSERT will fail if you''re passing an out-of-range index to the operator.

--

You should use assertions whenever and wherever you can. Really. If you are making an assumption, such as "this combination of flags is invalid", "this number must be positive", "this string cannot be empty", and if you''re not explicitly testing this assumption, you should at least put in the assertion. Assertions are commonly used to catch bugs in debug builds, and expand to nothing in release builds. The result is maximum speed in release and maximum robustness in debug.

quote:

If you are not making mistakes while programming ...


That is a very bold statement to make. You will make mistakes, and assertions will catch them. The beauty of assertions is that they tell you exactly what the problem is. While it may be easy to debug access violation resulting from an out-of-range index, with assertions there is no need for debugging. Some bugs that are very easy to find with assertions (logic errors, for example) are very hard to find without them.

quote:

Also, if anyone happens to know the bit of code that allows you to output to the watch window of VC++6.0 in debug mode let me know!

I don''t, but you can use OutputDebugString to write to the output (Alt-2) window.

Share this post


Link to post
Share on other sites
Writing 100 lines of c++ code is pretty easy to do without major bugs. But once your program grows, it''s really helpful to use every possible tool to discover bugs as soon as possible.

Suppose you work on a big project. Maybe you''ve inherited code from someone else, who now has left the building. You might have some other programmers on the team. You''re a bit tired and pass an incorrect parameter to an API written by the programmer who left building. Bang, "ASSERTION FAILURE: Parameter x must be in range [17, 4711]". If the assertion hadn''t been there in the first place it might have taken hours to find out.

You can of course do all these checks in runtime. But since assertions go away in Release builds, they don''t hurt performance. Thus you can do much more rigorous checks easily in debug builds.

One thing I always assert on is CloseHandle(). If that function fails, it means I closed an handle that wasn''t valid. This is a major bug, which could be really hard to find.

Assertion is typically something you should do for function parameters when someone is using your code. Assertion is typically something you should NOT use for things that can fail in runtime, such as malloc() returning NULL or a file wasn''t found on disk.

One book I would recommend is "Writing Solid Code". It describes all kind of techniques for writing code C-code. But much of the general thinking is useful in C++, Java and C# as well. See http://www.amazon.com/exec/obidos/ASIN/1556155514/qid=1024952813/sr=8-1/ref=sr_8_1/002-3446006-9143248

Share this post


Link to post
Share on other sites
Assertions are wonderful, and you''d be wise to make use of them. You are right to assume that the goal of them is to do extra checking of your data to ensure that it is "legal". A program with any non-trivial level of complexity will inevitably take a path that you didn''t think of. Using asserts will raise that red flag whenever this happens. In other words, your data SHOULD be legit, but in reality, it''s not so simple, and data sometimes gets erroneous values. Asserts will help you to track down these kinds of things that would otherwise go unnoticed. Your program would just crash occasionally and you''d blame Windows or video drivers, and you''d never figure out why the crash was happening. If you use asserts, you''ll get a message saying that you had an invalid index into an array or something, and you have a big head start in debugging the problem.

I''m writing a chess program, and it can get quite buggy, like I''m sure a graphics engine will. I''ve written each of my classes with a private method named _invariant(); which has a list of assert()''s in it, to verify that a piece doesn''t have an index that is off the board, for example. Basically I just go nuts with the asserts inside of _invariant() and my program lets me know if anything is wrong. At the very least, if my program keeps on running with no problems, then I know that it''s not going to crash. It might not make the best move sometimes because of a bug, but at least it''s going to make SOME move, and that''s better than crashing.

The final thing that is great about assert()''s is that they only run when you compile in debug mode. When you compile in release mode, they don''t run. So if you run your program in debug mode, and it runs without any of the assert()''s failing, then you can be pretty sure that it''s going to run just fine when you compile it in release mode, and then it''ll be faster since there is no data testing going on anymore.

I''d highly recommend using asserts with anything that gets complex.

Russell

Share this post


Link to post
Share on other sites
Thanks for the quick replies! I will take some time this evening to implement assertion handling.

While I am a pro using the VC++ debugger now, I can understand how useful this kind of checking can be! While I like to assume that I never make mistakes I know that things happen (Debugging a recent compiler project was hell - Knowing exactly when and where an error occured would have saved a lot of time!).

Sometimes I just need to understand why I need to use something before I will use it. Your expert opinions/explanation will save me hours of wasted time! I did not know:

"When you compile in release mode, they don''t run" - Russell

"The beauty of assertions is that they tell you exactly what the problem is. While it may be easy to debug access violation resulting from an out-of-range index, with assertions there is no need for debugging. Some bugs that are very easy to find with assertions (logic errors, for example) are very hard to find without them." - IndirectX

Clearly, this saves debug time, which can take a long time in the life of a big project!

I wanted to say that you guys (gamedev forum community) are great, always helpful, and cool regardless of how simple or stupid a question seems to be! I am thankful that there is a place where people can discuss these ideas! Thanks again!

Regards,

Share this post


Link to post
Share on other sites