Excerpt from "High Quality C / C Programming Guide" Page 41-42 ...
The program is generally divided into debug version and release version, and the Debug version is used for internal debugging, and the Release version is issued to the user. Assert is a macro that works only on the Debug version, it is used to check the situation that "should not" happen. Example 6-5 is a memory replication function. During the run, if the parameter of Assert is a false, the program will abort (generally show the dialogue, which means where ASSERT is triggered).
Void * Memcpy (void * pvfrom, size_t size) {assert ((pvfrom! = null) && (pvfrom! = null)); // Using assertion BYTE * PBTO = (Byte *) PVTO; // Preventing the address of PVTO from PBFROM = (byte *) PVFROM; / / Prevents the address of the PVFROM from WHILE (Size -> 0) * PBTO = * PBFROM ; Return PVTO;} Example 6-5 Copy Overlapping memory block
Assert is not a macro of a rush. In order not to cause a difference between the Debug version and the Release version, Assert should not generate any side effects. So Assert is not a function, but a macro. Programmers can see Assert as a honey-impaired test means that can be safely used in any system state. If the program terminates at Assert, it is not to say that the function containing the Assert has an error, but the caller has an error, and Assert can help us find the cause of the error.
I rarely compare the assertion of the procedure, but I don't know if the role of the assert is more depressed. You have been a lot of time, not to troubleshoot, but just to figure out what this error is. Sometimes, programmers can occasionally design errors. So if you can't figure out what is checked, it is difficult to judge that the error is in the program, or it appears in the assertion. Fortunately, this problem is very good, just add a clear annotation. This is an obvious thing, but there are very few programmers. This is better than a person in the forest, seeing a "dangerous" big brand on the tree. But what is dangerous? Do you want to fall? Is there a waste well? Is there a beast? This warning card is difficult to play an active effect unless it tells people "dangerous". It is difficult to understand that it is often overlooked by programmers or even deleted.
[Rule 6-5-1] Use asserts to capture illegal conditions that should not occur. Do not confuse the difference between illegal conditions and error conditions, the latter inevitably exist and must be processed. [Rule 6-5-2] At the entrance to the function, the validity of the assertion check parameters (legitimacy) is used. [Recommendation 6-5-1] When writing a function, it is necessary to make a repeated exam, and ask yourself: "What assumes I plan?" Once the assumption is determined, it is necessary to check the assumption using the assertion. [Recommendation 6-5-2] General textbooks encourage programmers to perform anti-wrong design, but remember that this programming style may hide errors. When the error is performed, if the "impossible" thing does occur, you should use the assertion to conduct alarm.
The elements that should be included in the Assert macro:
Judgment conditions; output the current assertion failed (file, line number, etc.); return errors; termination procedures ...
Several typical ASSERT's way:
Writing in VC:
#define assert (f) / do / {/ if (! (f) && AfxassertfailedLine (this_file, __line__)) / AFXDebugBreak (); /} while (0) / # define _assert (expr) / do {= EXPR) && / (1 == _CRTDBGREPORT (_CRT_ASSERT, __FILE__, __LINE__, NULL, NULL))) / _CRTDBGBREAK ();} while (0)
Other platforms:
# Define assert (x) ((x) || ("Assertion Failed (" __file __ ":% d): /"% s / "/ n", __ line __, # x), break_point (), false))
