tools.htm

一个非常适合初学者入门的有关c++的文档

C++ found in many popular class libraries.  <A HREF="TOOLS.HTM#rule15" ONMOUSEOVER = "self.status = 'Rule 15'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">Rule 15</A></NOBR> (no public data
members), for example, is widely violated in the Microsoft Foundation
Classes, while almost no library adheres to <A HREF="TOOLS.HTM#rule19" ONMOUSEOVER = "self.status = 'Rule 19'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">Rule 19</A></NOBR> (make all non-leaf
classes abstract).  With the exceptions of Rules <A HREF="TOOLS.HTM#rule13" ONMOUSEOVER = "self.status = ''; return true" ONMOUSEOUT = "self.status = self.defaultStatus">13</A></NOBR> and <A HREF="TOOLS.HTM#rule23" ONMOUSEOVER = "self.status = '23'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">23</A></NOBR> (which, in
this article, we hope are self-explanatory), <A HREF="../EC/INDEX.HTM" TARGET="_top" ONMOUSEOVER="self.status='Effective C++'; return true" ONMOUSEOUT = "self.status = self.defaultStatus"><I>Effective C++</I></A></NOBR> and
<A HREF="../MEC/INDEX.HTM" TARGET="_top" ONMOUSEOVER="self.status='More Effective C++'; return true" ONMOUSEOUT = "self.status = self.defaultStatus"><I>More Effective C++</I></A></NOBR> offer firm technical foundations for each
rule.  We believe it is therefore important that programmers be able to
enforce those constraints, even if the majority of programmers choose
not to.  Furthermore, our decision to include rules that are commonly
violated helps us evaluate the effectiveness of the tools' filtering
capabilities.  (We do not report on this aspect of the tools in this
paper, but it is an important consideration in the practical application
of any tool; see <NOBR>below.)<SCRIPT>create_link(32);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp33"></A><FONT ID="aititle">Benchmark Programs</FONT><SCRIPT>create_link(33);</SCRIPT>

</P>

<P><A NAME="dingp34"></A><A NAME="AUTO00031"></A>For each of our 36 rules, we developed a trivial source file seeded
with a violation of the rule.  We then executed each tool on each source
file to see if the tools correctly identified the seeded errors.  These
source files were truly <I>trivial</I> &#151; many were under 10 lines
long.  Our goal with these files was not to provide a realistic test of
the tools, it was just to see whether the tools could identify rule
violations in the simplest of cases.  (Sometimes this backfired and
yielded misleading results &#151; see <NOBR>below.)<SCRIPT>create_link(34);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp35"></A><A NAME="AUTO00032"></A>As an example, here is the complete source code for the file used to
test <A HREF="TOOLS.HTM#rule20" ONMOUSEOVER = "self.status = 'Rule 20'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">Rule 20</A></NOBR>:<SCRIPT>create_link(35);</SCRIPT>

</P>

<A NAME="AUTO00082"></A><UL><PRE>
//    20  <SCRIPT>sendmetoo(24,41284,'M');</SCRIPT> ONMOUSEOVER = "self.status = 'M24'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" >M24</A></NOBR>  Avoid gratuitous use of virtual inheritance, i.e., make
//             sure there are at least two inheritance paths to each
//             virtual base class.

class Base { int x; };
class Derived: virtual public Base {};

Derived d;
</PRE>
</UL>

<P><A NAME="dingp36"></A><FONT ID="aititle">Compilers Versus Special Tools</FONT><SCRIPT>create_link(36);</SCRIPT>

</P>

<P><A NAME="dingp37"></A><A NAME="AUTO00033"></A> Several people responded to our request for information on static
analysis tools by remarking that they found little need for such
tools.  Instead, they wrote, they relied on their compilers to flag
conditions that were likely to lead to trouble.  The following comment
was <NOBR>typical:<SCRIPT>create_link(37);</SCRIPT>

</NOBR></P>

<A NAME="AUTO00034"></A>
<CENTER>
<CITE>
  I find GNU G++ with -ansi -pedantic -Wall -O flags useful.
</CITE>
</CENTER>

<P><A NAME="dingp38"></A><A NAME="AUTO00035"></A>In fact, the Gnu compiler was singled out by more than one writer as
being especially good at warning about troublesome C++.  This piqued our
curiosity about compiler warnings.  How many of our candidate rules
would compilers <NOBR>identify?<SCRIPT>create_link(38);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp39"></A><A NAME="AUTO00036"></A>To find out, we submitted our benchmark programs to five compilers,
in each case enabling as many warnings as possible.  As <A HREF="TOOLS.HTM#table3" ONMOUSEOVER = "self.status = 'Table 3'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">Table 3</A></NOBR> shows,
the results were disappointing.  Even g++ identified at most two of the
36 rule violations, and three of the compilers identified none.  This
confirmed our impression (based on our experience as C++ programmers)
that compilers are good at many things, but identifying legal, but
potentially troublesome, C++ source code is not one of <NOBR>them.<SCRIPT>create_link(39);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp40"></A><FONT ID="aititle">Specifying Constraints</FONT><SCRIPT>create_link(40);</SCRIPT>

</P>

<P><A NAME="dingp41"></A><A NAME="AUTO00037"></A>The tools in our study allow programmers to specify what conditions
to check for in one of two ways.  Most tools follow the <CODE>lint</CODE> model,
whereby the tool is created with the ability to enforce some set of
predefined constraints, and programmers turn these constraints on or
off.  There is no way to extend the capabilities of such tools.  For
example, a tool is either capable of detecting that an exception may
leave a destructor (<A HREF="TOOLS.HTM#rule31" ONMOUSEOVER = "self.status = 'Rule 31'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">Rule 31</A></NOBR>) or it's not.  If it's not, there is no way for a tool user to add that <NOBR>capability.<SCRIPT>create_link(41);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp42"></A>A different approach, one employed by <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=abraxas_software" ONMOUSEOVER = "self.status = 'Abraxas Software Home Page'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" TARGET="_top">Abraxas</A></NOBR>' <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=codecheck" ONMOUSEOVER = "self.status = 'CodeCheck Home Page'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" TARGET="_top">Codecheck</A></NOBR> and<NOBR>
<FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=hp" ONMOUSEOVER = "self.status = 'Hewlett Packard Home Page'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" TARGET="_top">HP's</a> <FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=codeadvisor" ONMOUSEOVER = "self.status = 'CodeAdvisor Home Page'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" TARGET="_top">CodeAdvisor</A></NOBR>, and our research program CCEL, is to provide tool users
with a language in which to express constraints of their own.  Such
tools may or not be useful "out of the box" (it depends on the existence
and utility of predefined rule libraries), but they can be extended to
check for new, user-defined conditions.  This approach is more powerful,
but, as in the case of C++ itself, complexity often accompanies power.
The power is inaccessible until one has mastered the constraint
expression language.  Furthermore, the addition of user-defined
constraints may affect an analysis tool's performance, because
enforcement of such constraints may require arbitrary amounts of time,
memory, or other <NOBR>resources.<SCRIPT>create_link(42);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp43"></A><A NAME="AUTO00039"></A>We made no attempt to master the various constraint expression
languages used by the different tools, but the examples we saw (see the
<A HREF="#appendix" ONMOUSEOVER = "self.status = 'appendix'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">appendix</A></NOBR>) reinforced the lessons we learned
during the design and implementation of CCEL: it's hard to design a
language for expressing constraints on a language as feature-filled as
C++, and given such a constraint language, it's nontrivial to learn to
use it.  <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=abraxas_software" ONMOUSEOVER = "self.status = 'Abraxas Software Home Page'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" TARGET="_top">Abraxas</NOBR></A></NOBR>, for example, reports that it takes between 3 and 6
months to become proficient in the <NOBR><FONT COLOR="#FF0000" SIZE="-2"><B>&deg;</B></FONT><A HREF="http://www.awl.com/cseng/cgi-bin/cdquery.pl?name=codecheck" ONMOUSEOVER = "self.status = 'CodeCheck Home Page'; return true" ONMOUSEOUT = "self.status = self.defaultStatus" TARGET="_top">CodeCheck</NOBR></A></NOBR> constraint language.  Most
of their customers hire specialists to compose their rules instead of
learning to write the rules <NOBR>themselves.<SCRIPT>create_link(43);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp44"></A><A NAME="AUTO00040"></A>Most programmable tools attempt to offer the best of both worlds by
shipping with a set of predefined rule libraries that check for
commonly-desired constraints.  This eliminates the need to write rules
to cover common <NOBR>constraints.<SCRIPT>create_link(44);</SCRIPT>

</NOBR></P>

<P><A NAME="dingp45"></A><FONT ID="aititle">Results And Discussion</FONT><SCRIPT>create_link(45);</SCRIPT>

</P>

<P><A NAME="dingp46"></A><A NAME="AUTO00041"></A>The results of running the various tools on the collection of benchmark
programs is shown in <A HREF="TOOLS.HTM#table3" ONMOUSEOVER = "self.status = 'Table 3'; return true" ONMOUSEOUT = "self.status = self.defaultStatus">Table 3</A></NOBR>.<SCRIPT>create_link(46);</SCRIPT>

</P>

<A NAME="AUTO00042"></A>