21:          for(i=0;i&lt;arNumbers.GetSize()-1;i++)22:          {23:              if (arNumbers[i] &gt; arNumbers[i+1])24:              {25:                  Swap(&amp;arNumbers,i);26:                  bSorted = FALSE;27:              }28:          }29:      } while(!bSorted);30:31:      TRACE(&quot;After Sort\n&quot;);32:      for(i=0;i&lt;arNumbers.GetSize();i++)33:          TRACE(&quot;[%d] = %d\n&quot;,i+1,arNumbers[i]);34:  }</PRE><P>Listing E.1 sorts an array of random numbers (between 1 and 100), generated inline 11. Lines 13 to 15 then print out the contents of the array before sorting byTRACE statements. Lines 17 through 29 sort the array by swapping pairs of numbersthat are in the wrong order (by calling the Swap() function in line 25). The Swap()function (lines 1 to 6) takes a pointer to the array and a position and then swapsthe two numbers at that position.</P><P>After sorting, the contents of the array are again printed in the output windowby the TRACE statements in lines 31 to 33.</P><P>The trace output of this program appears in the Output window of Developer Studio,as shown in Table E.3.</P><P><H4>TABLE E.3.&nbsp;OUTPUT FROM THE SORTING PROGRAM.</H4><P><TABLE BORDER="1">	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">			<H4>BEFORE SORT		</TD>		<TD ALIGN="LEFT">			<H4>AFTER SORT		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[1] = 42		</TD>		<TD ALIGN="LEFT">[1] = 1		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[2] = 68		</TD>		<TD ALIGN="LEFT">[2] = 25		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[3] = 35		</TD>		<TD ALIGN="LEFT">[3] = 35		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[4] = 1		</TD>		<TD ALIGN="LEFT">[4] = 42		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[5] = 70		</TD>		<TD ALIGN="LEFT">[5] = 59		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[6] = 25		</TD>		<TD ALIGN="LEFT">[6] = 63		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[7] = 79		</TD>		<TD ALIGN="LEFT">[7] = 65		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[8] = 59		</TD>		<TD ALIGN="LEFT">[8] = 68		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[9] = 63		</TD>		<TD ALIGN="LEFT">[9] = 70		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD ALIGN="LEFT">[10] = 65		</TD>		<TD ALIGN="LEFT">[10] = 79		</TD>	</TR></TABLE><H3><A NAME="Heading10"></A>Using the ASSERT and VERIFY macros</H3><P>You can use the ASSERT macro to ensure that conditions are TRUE. ASSERT is passedone parameter that is either a TRUE or FALSE expression. If the expression is TRUE,all is well. If the expression is FALSE, your program will stop and the Debug AssertionFailed dialog box will be displayed (see Figure E.7), prompting you to Abort theprogram, Retry the code, or Ignore the assertion. It also shows the program, sourcefile, and line number where the assertion failed. If you choose Abort, the debuggingsession is terminated. Retry is probably the most useful option because the compilerwill then show you the code where the ASSERT macro has failed, enabling you to figureout what went wrong. If you already know or don't care about the assertion, you canchoose Ignore and continue running the program, which might then result in a morefatal error.</P><P><A HREF="javascript:popUp('30fig07.gif')"><B>FIGURE E.7.</B></A><B> </B><I>TheDebug Assertion Failed dialog box helps you track down bugs.</I></P><P>A common use of ASSERT is to ensure that input parameters to functions are correct.For example, you can make the Sort() function (shown in Listing E.1) more robustby checking its input parameters. To check the input parameters, add ASSERT macrosat the top of the Sort() function like this:</P><P><PRE>ASSERT(pdwNumbers);ASSERT(i&gt;=0 &amp;&amp; i&lt;10);</PRE><P>This will ensure that the pointer to the numbers array isn't zero and that theposition to swap is between 0 and 9. If either of these is incorrect, the Debug AssertionFailed dialog box is displayed. This technique helps you track down errors causedby passing faulty parameters to functions. It is a good practice to use the ASSERTmacro to check that the values passed to each of your functions conform to your expectations.</P><P>Another macro, ASSERT_VALID, can be used with CObject-derived classes such asmost MFC classes. This performs a more thorough check on the object and its contentsto ensure the entire object is in a correct and valid state. You can pass a pointerto the object to be checked like this:</P><P><PRE>ASSERT_VALID(pdwNumbers);</PRE><P>Another ASSERT macro is ASSERT_KINDOF, which is used on CObject-derived classesto check that they are of the correct class type. For example, you can check thata pointer to your view object is of the correct view class like this:</P><P><PRE>ASSERT_KINDOF(CYourSpecialView,pYView);</PRE><P>The Assertion Failed dialog box will be displayed if it isn't of the correct classtype or any of its derivatives.</P><P>You must be careful not to put any code that is needed for normal program operationinto ASSERT macros because they are excluded in the release build. A common sourceof release mode errors that are hard to track down is coding like this:</P><P><PRE>int a = 0;ASSERT(++a &gt; 0);if (a&gt;0) MyFunc();</PRE><P>In the debug build, this code will increment the integer a in the ASSERT lineand then call MyFunc() in the following line because a is greater than zero. Whenyour sales team is eager to demonstrate your new application, you might think itworks fine because there aren't any Debug mode problems. So you recompile it in Releasemode and hand it over to your sales department, which demonstrates it to a customer,whereupon it crashes badly. It crashes because the ++a isn't performed--the releasemode excludes ASSERT lines.</P><P>The VERIFY macro helps with this problem. VERIFY works like ASSERT, and in Debugmode it throws the same Assertion Failed dialog box if the expression is zero. However,in release mode the expression is still evaluated, but a zero result won't displaythe Assertion dialog box. You will tend to use VERIFY when you always want to performan expression and ASSERT when you only want to check while debugging. Therefore,replacing ASSERT in the previous example with VERIFY, as shown in the following example,will enable the release build to work properly:</P><P><PRE>VERIFY(++a &gt; 0);</PRE><P>You are more likely to use VERIFY to check return codes from functions:</P><P><PRE>VERIFY(MyFunc() != FALSE);</PRE><H3><A NAME="Heading11"></A>Using Breakpoints and Single Stepping the Program</H3><P>The use of single stepping and breakpoints is probably the most effective debuggingtool for tracking down the majority of problems. The support for various types ofbreakpoints and the single-stepping information available is very sophisticated inVisual C++; I can only hope to give you a taste of the power of this debugging tool.</P><P>The key to single stepping is breakpoints. You can set a breakpoint anywhere inyour code and then run your program through the debugger. When the breakpoint isreached, the code will be displayed in the editor window at the breakpoint position,ready for you to single step or continue running.</P><P>You can add a breakpoint by selecting the specific code line (clicking the editorcursor onto the line in the editor window) and then either clicking the Breakpointicon in the Build minibar (see Figure E.8) or by pressing F9. Alternatively, mostsophisticated breakpoints can be added or removed by clicking the Edit menu and selectingthe Breakpoints option to display the Breakpoints dialog box (see Figure E.9). Whenyou add a breakpoint, it's displayed as a small red circle next to the line you havespecified. Breakpoints can be set only against valid code lines, so sometimes theDeveloper Studio will move one of your breakpoints to the closest valid code linefor you.</P><P><A HREF="javascript:popUp('30fig08r.gif')"><B>FIGURE E.8.</B></A><B> </B><I>Addinga breakpoint to your code via the Build minibar toolbar or the F9 key.</I></P><P><A HREF="javascript:popUp('30fig09.gif')"><B>FIGURE E.9.</B></A><B> </B><I>Addinga breakpoint using the Breakpoints dialog box.</I></P><P>You can toggle the breakpoint on or off by clicking the Breakpoint (hand shaped)icon or remove it by clicking the Remove or Remove All buttons on the Breakpointsdialog box. You can leave them in position but disable them by clicking the checkmark to the left of each breakpoint listed in the Breakpoints dialog box. Clickingthere again will show the check and re-enable the breakpoint.</P><P>When you have set your breakpoint(s), you can run the code through the debuggerby choosing Build, Start Debug, Go. Alternatively, you can use the shortcut by clickingthe Go icon (to the left of the Breakpoint icon on the Build minibar toolbar--referto Figure E.8) or by pressing the F5 key.</P><P>The program will run as normal until it reaches the breakpoint, where it willstop and display an arrow against the line with the breakpoint. At that point, youcan use the Debug toolbar to control the single stepping process, as shown in FigureE.10.</P><P><A HREF="javascript:popUp('30fig10r.gif')"><B>FIGURE E.10.</B></A><B> </B><I>Thedebugger stopped at a breakpoint ready for single stepping with the Debug toolbar.</I></P><P>When stopped in the debugger, you can see the contents of most variables merelyby moving the cursor over them in the editor window. Their contents are then displayedin a ToolTip at the cursor position. More detailed contents are shown by draggingthe variables into the Watch window, as discussed in detail in the next section.</P><P>You can single step through the code using the four curly brace icons shown onthe Debug toolbar or by clicking the Debug menu and choosing one of the step options.The available step options are shown in Table E.4. You can find these on the Debugmenu and the Debug toolbar.</P><P><H4>TABLE E.4. STEP OPTIONS AVAILABLE IN SINGLE STEPPING.</H4><P><TABLE BORDER="1">	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><I>Icon/Step Option</I></TD>		<TD ALIGN="LEFT"><I>Shortcut Key</I></TD>		<TD ALIGN="LEFT"><I>Effect When Selected</I></TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><IMG SRC="ic-12.gif" WIDTH="29" HEIGHT="28" ALIGN="BOTTOM" BORDER="0"> Step Into		</TD>		<TD ALIGN="LEFT">F11		</TD>		<TD ALIGN="LEFT">The debugger will execute the current line and if the cursor is over a function call,			it will enter that function.		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><IMG SRC="ic-13.gif" WIDTH="29" HEIGHT="28" ALIGN="BOTTOM" BORDER="0"> Step Over		</TD>		<TD ALIGN="LEFT">F10		</TD>		<TD ALIGN="LEFT">Like Step Into except when over a function call line, it will run that function at			normal speed and then stop when it returns from the function, giving the effect of			stepping over it.		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><IMG SRC="ic-14.gif" WIDTH="29" HEIGHT="28" ALIGN="BOTTOM" BORDER="0"> Step Out		</TD>		<TD ALIGN="LEFT">Shift+F11		</TD>		<TD ALIGN="LEFT">The debugger will run the rest of the current function at normal speed and stop when			it returns from the function to the calling function.		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><IMG SRC="ic-15.gif" WIDTH="29" HEIGHT="28" ALIGN="BOTTOM" BORDER="0"> Run to Cursor		</TD>		<TD ALIGN="LEFT">Ctrl+F10		</TD>		<TD ALIGN="LEFT">The debugger will run until it reaches your specified cursor position. You can set			this position by clicking the line you want to run to.		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><IMG SRC="ic-05.gif" WIDTH="29" HEIGHT="28" ALIGN="BOTTOM" BORDER="0"> Go		</TD>		<TD ALIGN="LEFT">F5		</TD>		<TD ALIGN="LEFT">Continue running the program at normal speed until the next breakpoint is encountered.		</TD>	</TR>	<TR ALIGN="LEFT" VALIGN="TOP">		<TD WIDTH="134" ALIGN="LEFT"><IMG SRC="ic-08.gif" WIDTH="24" HEIGHT="27" ALIGN="BOTTOM" BORDER="0"> Stop Debugging		</TD>		<TD ALIGN="LEFT">Shift+F5		</TD>