📄 ch24.htm
字号:
<HTML>
<HEAD>
<TITLE>Special Edition Using Visual C++ 5 - Chapter 24</TITLE>
<LINK REL="Next" HREF="ch25.htm" tppabs="http://www.mcp.com/814147200/0-7897/0-7897-1145-1/ch25.htm">
<LINK REL="Previous" HREF="ch23.htm" tppabs="http://www.mcp.com/814147200/0-7897/0-7897-1145-1/ch23.htm"></HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H2><A ID="I1" NAME="I1"><B>Chapter 24</B></A></H2>
<H2><A ID="I2" NAME="I2"></A><B>Improving Your Application's Performance</B></H2>
<hr>
<P>When developing a new application, there are various hurdles developers need to overcome. You have to get your application to compile, to run without blowing up, and you have to be sure that it does what you want it to do. On some projects, there is
time to determine if your application can run faster, use less memory, or if you can have a smaller executable file. The performance improvement techniques discussed in this chapter can prevent your program from blowing up, and prevent the kind of
“thinkos” that result in a program calculating or reporting the wrong numbers. These improvements are not just final tweaks and touch-ups on a finished product.</P>
<P>You should get in the habit of adding “an ounce of prevention” to your code as you write, and of using the debugging capabilities provided to you by Developer Studio to be sure of what’s going on in your program. If you save all your
testing to the end, both the testing and the bug-fixing will be much harder than if you had been testing all along. And, of course, any bug you manage to prevent will never have to be fixed at all!</P>
<ul>
<li> <B>Employing </B><B><font color="#008000">ASSERT</font></B><B> and </B><B><font color="#008000">TRACE</font></B></P>
<P> Assertions prevent trouble, and trace statements show you what’s going on. These macros belong in every program.</P>
<li> <B>Memory leaks</B></P>
<P> When your application allocates memory but never frees it, you have a memory leak. See what causes them, how to find them, and how to eliminate them.</P>
<li> <B>Optimization</B></P>
<P> You can produce faster or smaller code today, simply by asking the compiler to optimize for you. Learn what options are available and how to make your decision.</P>
<li> <B>Profiling</B></P>
<P> Too many programmers sweat bullets trying to speed up code that is rarely called, while ignoring slow code that is causing a bottleneck. Profiling shows you where to spend your energy.</P>
</ul>
<H3><A ID="I3" NAME="I3"><B>ASSERT and TRACE</B></A></H3>
<P>The concepts of asserting and tracing were not invented by the developers of Visual C++. Other languages support these ideas, and they are taught in many computer science courses. What is exciting about the Visual C++ implementation of these concepts
is the clear way in which your results are presented, and the ease with which you can suppress assertions and trace statements in release versions of your application.</P>
<P><A ID="I4" NAME="I4"><B>ASSERT</B><B><I>: Detecting Logic Errors</I></B></A></P>
<P>The <font color="#008000">ASSERT</font> macro allows you to check a condition that you logically believe should always be true. For example, imagine you are about to access an array like this:</P>
<pre><font color="#008000">array[i] = 5;</font></pre>
<P>You want to be sure that the index, <font color="#008000">i</font>, is not less than zero and is not larger than the number of elements allocated for the array. Presumably you have already written code to calculate <font color="#008000">i</font>, and
if that code has been written properly, <font color="#008000">i</font> must be between 0 and the array size. An <font color="#008000">ASSERT</font> statement will verify that:</P>
<pre><font color="#008000">ASSERT( i > 0 && i < ARRAYSIZE)</font></pre>
<blockquote><p><img src="note.gif" tppabs="http://www.mcp.com/814147200/0-7897/0-7897-1145-1/note.gif">
<P>There is no semicolon (<font color="#008000">;</font>) at the end of the line because <font color="#008000">ASSERT</font> is a macro, not a function. Older C programs may call a function named <font color="#008000">assert()</font>, but you should
replace these calls with the <font color="#008000">ASSERT</font> macro, because <font color="#008000">ASSERT</font> disappears during a release build, as discussed later in this section.</P>
<p><img src="bottom.gif" tppabs="http://www.mcp.com/814147200/0-7897/0-7897-1145-1/bottom.gif"></blockquote>
<p><font color="#008000">ASSERT</font> statements are ways for you to check your own logic. They should never be used to check for user input errors or bad data in a file. Whenever the condition inside an <font color="#008000">ASSERT</font> statement is
false, program execution halts with a message telling you which assertion failed. At this point, you know you have a logic error, or a developer error, that you need to correct. Here’s another example:</P>
<pre><font color="#008000">// Calling code must pass a non-null pointer </font></pre>
<pre><font color="#008000">void ProcessObject( Foo * fooObject )</font></pre>
<pre><font color="#008000">{</font></pre>
<pre><font color="#008000"> ASSERT( fooObject )</font></pre>
<pre><font color="#008000"> // process object</font></pre>
<pre><font color="#008000">}</font></pre>
<P>This code can de-reference the pointer in confidence, knowing execution will be halted if the pointer is null.</P>
<P>You probably already know that Developer Studio makes it simple to build debug and release versions of your programs. The Debug version #defines a constant, <font color="#008000">_DEBUG</font>, and macros and other pre-processor code can check this
constant to determine the build type. When <font color="#008000">_DEBUG</font> is not defined, the <font color="#008000">ASSERT</font> macro does nothing. This means there is no speed constraint in the final code as there would be if you added <font
color="#008000">if</font> statements yourself to test for logic errors. There is no need for you to go through your code removing <font color="#008000">ASSERT</font> statements when you release your application, and in fact it’s better to leave them
there to help the developers who work on version 2. In addition, <font color="#008000">ASSERT</font> cannot help you if there is a problem with the release version of your code because it is used to find logic and design errors before you release version
1.0 of your product.</P>
<P><B><I> </I></B><A ID="I5" NAME="I5"><B>TRACE</B><B><I>: Isolating Problems Areas in Your Program</I></B></A></P>
<P>As discussed in <A HREF="indexc.htm" tppabs="http://www.mcp.com/814147200/0-7897/0-7897-1145-1/indexc.htm" target="text">Reference Chapter C</A>, “Debugging,” the power of the Developer Studio debugger is considerable. You can step through your code one line at a time, or run to a breakpoint, and you can see
the values of any of your variables in watch windows as you move through the code. This can be slow, however, and many developers use <font color="#008000">TRACE</font> statements as a way of speeding up this process and zeroing in on the problem area.
Then they turn to more traditional step-by-step debugging to isolate the bad code.</P>
<P>In the old days, isolating bad code meant adding lots of <font color="#008000">print</font> statements to your program, which is problematic in a Windows application. So before you start to think up workarounds, like printing to a file, relax, because
the <font color="#008000">TRACE</font> macro does everything you want. And like <font color="#008000">ASSERT</font>, it magically goes away in release builds.</P>
<P>There are actually several <font color="#008000">TRACE</font> macros: <font color="#008000">TRACE</font>, <font color="#008000">TRACE0</font>, <font color="#008000">TRACE1</font>, <font color="#008000">TRACE2</font>, and <font
color="#008000">TRACE3</font>. The number-suffix indicates the number of parametric arguments beyond a simple string, working much like <font color="#008000">printf</font>. The different versions of <font color="#008000">TRACE</font> were implemented to
save data segment space.</P>
<P>When you generate an application with AppWizard, many <font color="#008000">ASSERT</font> and <font color="#008000">TRACE</font> statements are added for you. Here’s a <font color="#008000">TRACE</font> example:</P>
<pre><font color="#008000">if (!m_wndToolBar.Create(this)</font></pre>
<pre><font color="#008000"> || !m_wndToolBar.LoadToolBar(IDR_MAINFRAME))</font></pre>
<pre><font color="#008000">{</font></pre>
<pre><font color="#008000"> TRACE0("Failed to create toolbar\n");</font></pre>
<pre><font color="#008000"> return -1; // fail to create</font></pre>
<pre><font color="#008000">}</font></pre>
<P>If the creation of the toolbar fails, this routine will return <font color="#008000">-1</font>, which signals to the calling program that something is wrong. This will happen in both debug and release builds. But in debug builds, a trace output will be
sent that should help the programmer understand what went wrong.</P>
<P>All of the <font color="#008000">TRACE</font> macros write to <font color="#008000">afxDump</font>, which is usually the debug window, but can be set to <font color="#008000">stderr</font> for console applications. The number-suffix indicates the
parametric argument count, and you use the parametric values within the string to indicate the passed data type. For example, to send a <font color="#008000">TRACE</font> statement that includes the value of an integer variable:</P>
<pre><font color="#008000">TRACE1(“Error Number: %d\n”, -1 );</font></pre>
<P>Or, to pass two arguments, maybe a string and an integer:</P>
<pre><font color="#008000">TRACE2(“File Error %s, error number: %d\n”, __FILE__, -1 );</font></pre>
<P>The most difficult part of tracing is making it a habit. Sprinkle <font color="#008000">TRACE</font> statements anywhere you return error values: before <font color="#008000">ASSERT</font> statements, and in areas where you are not quite sure you
constructed your code correctly. When confronted with unexpected behavior, add <font color="#008000">TRACE</font> statements first so that you understand more of what is going on before you start debugging.</P>
<H3><A ID="I6" NAME="I6"><B>Debug Only Features</B></A></H3>
<P>If the idea of code that is not included in a release build appeals to you, you may want to arrange for some of your own code to be included in debug builds but not in release builds. It’s easy. Just wrap the code in a test of the <font
color="#008000">_DEBUG</font> constant, like this:</P>
<pre><font color="#008000">#ifdef _DEBUG</font></pre>
<pre><font color="#008000"> // debug code here</font></pre>
<pre><font color="#008000">#endif</font><font color="#008000"> </font></pre>
<P>In release builds, this code will not be compiled at all.</P>
<P>You can also use different settings for debug and release builds. For example, many developers use different compiler warning levels. All of the settings and configurations of the compiler and linker are kept separately for debug and release builds,
and can be changed independently. For example, to bump your warning level to 4 for debug builds only, follow these steps:</P>
<ol>
<li><P> Choose <U>P</U>roject, <U>S</U>ettings, which opens the Project Settings dialog box, shown in Figure 24.1.</P>
<li><P> Choose Debug or Release from the drop-down list box at the upper left. If you choose All Configurations you will change debug and release settings simultaneously.</P>
</ol>
<A HREF="Yfigs01.gif" tppabs="http://www.mcp.com/814147200/0-7897/0-7897-1145-1/figs/ch24/Yfigs01.gif"><b>Fig. 24.1</b></A>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -