Geek Answers Handbook

Is ASSERT redundant?

ASSERT(pointer); pointer->x;

In this code, ASSERT seems redundant. If the pointer is NULL, the pointer-> x will fail anyway. Is my argument correct?

+4
source share
7 answers

An important (if not the main) goal of statements is to document invariants that must be held at a certain point in the code. The fact that assert can also interrupt the program if the invariant is broken is just icing on the cake, albeit very useful. I would say that in a typical program, 90% of the statements are statements that obviously cannot fail and never fail. In other words, assert is pretty much a sort of formalized commentary language. Formalized in the sense that these "comments" are written in one language, the rest of the code is written in (C / C ++), and not plain English.

Your code example states that the pointer here should not be empty. That is why he is. In this sense, this assert not redundant.

As for the thread of execution, assert always redundant, so assertions are usually not compiled in the version version of the code. There is nothing to prevent you from storing statements in the release code, but this is usually done by introducing a special kind of “release statement”. In any case, if the core functionality of the code depends on the actions taken by the statement, it is not good programming practice. Statements should be redundant because the core functionality of the code.

+33
source

Yes, but pointer->x will (I suppose) crash in an uncontrolled way, while assert will fail and tell you exactly where.

In a sense, assert always redundant, of course.

+19
source

No, this is not redundant. The statement will stop executing before something bad happens. On the other hand, if you play the wrong pointer, you can cause real corruption, or at least an uncontrolled segfault, rather than a controlled abortion.

+2
source

In some cases, assert can be used to debug http://simonwillison.net/2008/May/22/debugging/

0
source

ASSERT not part of the C standard, so anything can be

  #define ASSERT(x) do { \ x = malloc ( sizeof *x ); \ memset ( x, 0, sizeof *x );\ } while ( 0 )

ASSERT is another matter.

Some people have an ASSERT macro that calls the debugger, some have another that does other debugging or logging, and uses the function of a string preprocessor.

You really need to say what the macro does for anyone who knows if it matters.

0
source

ASSERT can also be used to check for invalid or illogical conditions that might not cause a failure. Here is a terribly contrived example:

 void cpu_hog(int duration) { int start_time = (int) time(NULL); int end_time = start_time + duration; ASSERT(end_time > start_time); /* If this fails, "int" is too small. */ while ((int) time(NULL) < end_time) ; }

One small note: most ASSERT supporters recommend using it only to test the assumptions you make when writing code (for example, a pointer is not NULL or a condition cannot occur). It is generally thought that it is a bad idea to use ASSERT to catch user-related errors or exceptions that are expected to be executed (e.g. full disk), because (1) ASSERT exists only in the debug assembly and (2) even if you promote your production debugging code, it will crash and not process the condition gracefully.

0
source

ACCERT should not fail. Here the debugger stops at the breakpoint. This will not affect release builds.

-one
source

More articles:


All Articles