📄 ch02.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"><HTML><HEAD> <META NAME="Author" Content="Steph Mineart"> <META HTTP-EQUIV="Content-Type" CONTENT="text/html;CHARSET=iso-8859-1"> <TITLE>ANSI/ISO C++ Professional Programmer's Handbook - Chapter 2 - Standard Briefing: The Latest Addenda to ANSI/ISO C++ </TITLE> <link rel="stylesheet" TYPE="text/css" href="/includes/stylesheets/ebooks.css"></head><BODY TEXT="#000000" BGCOLOR="#FFFFFF"><CENTER><H1><img src="/publishers/que/series/professional/0789720221/button/que.gif" WIDTH="171" HEIGHT="66" ALIGN="BOTTOM" BORDER="0"><BR>ANSI/ISO C++ Professional Programmer's Handbook</H1></CENTER><CENTER> <P><A HREF="/publishers/que/series/professional/0789720221/index.htm"><img src="/publishers/que/series/professional/0789720221/button/contents.gif" WIDTH="128"HEIGHT="28" ALIGN="BOTTOM" ALT="Contents" BORDER="0"></A> <HR> <h1> 2</h1> <h1> Standard Briefing: The Latest Addenda to ANSI/ISO C++</h1> <div align="left"> <address>by Danny Kalev</address><H1> </H1><UL><LI><A HREF="#Heading1">Introduction</A><UL><LI><A HREF="#Heading2">Understanding the ANSI/ISO Standard</A><LI><A HREF="#Heading3">Purpose and Structure of This Chapter</A></UL><LI><A HREF="#Heading4">The Standard's Terminology</A><UL><LI><A HREF="#Heading5">Arguments and Parameters</A><LI><A HREF="#Heading6">Translation Unit</A><LI><A HREF="#Heading7">Program</A><LI><A HREF="#Heading8">Well-Formed Program</A><LI><A HREF="#Heading9">lvalues and rvalues</A><LI><A HREF="#Heading10">Behavior Types</A><LI><A HREF="#Heading11">The One Definition Rule</A><LI><A HREF="#Heading12">Linkage Types</A><LI><A HREF="#Heading13">Side effect</A></UL><LI><A HREF="#Heading14">Addenda</A><UL><LI><A HREF="#Heading15">New Typecast Operators</A><LI><A HREF="#Heading16">Built-in bool Type</A><LI><A HREF="#Heading17">Exception Handling</A><LI><A HREF="#Heading18">Memory Management</A><LI><A HREF="#Heading19">Constructors and Destructors</A><LI><A HREF="#Heading20">Local Definitions and Scoping Rules</A><LI><A HREF="#Heading21">Namespaces</A><LI><A HREF="#Heading22">Templates</A><LI><A HREF="#Heading23">The Standard Template Library</A><LI><A HREF="#Heading24">Internationalization and Localization</A><LI><A HREF="#Heading25">Miscellaneous</A></UL><LI><A HREF="#Heading26">Deprecated Feature</A><UL><LI><A HREF="#Heading27">Use of an Operand of Type bool with the Postfix ++ Operator</A><LI><A HREF="#Heading28">Use of static to Declare Objects in Namespace Scope</A><LI><A HREF="#Heading29">Access Declarations</A><LI><A HREF="#Heading30">Implicit Conversion from const to non-const Qualification for String Literals</A><LI><A HREF="#Heading31">Standard C Headers in the form <name.h></A><LI><A HREF="#Heading32">Implicit int Declarations</A><LI><A HREF="#Heading33">Other Deprecated Features</A></UL><LI><A HREF="#Heading34">Conclusions</A></UL><hr size=4> <h2><a name="Heading1">Introduction</a></h2> <p>C++ today is very different from what it was in 1983, when it was first named "C++". Many features have been added to the language since then; older features have been modified, and a few features have been deprecated or removed entirely from the language. Some of the extensions have radically changed programming styles and concepts. For example, downcasting a base to a derived object was considered a bad and unsafe programming practice before the standardization of Runtime Type Information. Today, downcasts are safe, and sometimes even unavoidable. The list of extensions includes <tt>const</tt> member functions, exception handling, templates, new cast operators, namespaces, the Standard Template Library, <tt>bool</tt> type, and many more. These have made C++ the powerful and robust multipurpose programming language that it is today.</p> <p>The evolution of C++ has been a continuous and progressive process, rather than a series of brusque revolutions. Programmers who learned C++ only three or five years ago and haven't caught up with the extensions often discover that the language slips through their fingers: Existing pieces of code do not compile anymore, others compile with a plethora of compiler warnings, and the source code listings in object-oriented magazines seem substantially different from the way they looked not so long ago. "Namespaces? never heard of these before," and "What was wrong with C-style cast? Why shouldn't I use it anymore?" are some of the frequently asked questions in various C++ forums and conferences.</p> <h3> <a name="Heading2">Understanding the ANSI/ISO Standard</a></h3> <p>But even experienced C++ programmers who have kept up with changes by subscribing to newsgroups, reading magazines and books, or exchanging emails with the company's guru might still find that the C++ nomenclature in professional literature is sometimes unclear. The ANSI/ISO Standard is written in a succinct and technical jargon that is jocularly called <i>standardese</i> -- which is anything but plain English. For instance, the <i>One Definition Rule</i> (article 3.2 in the Standard), which defines under what conditions separate definitions of the same entity are valid, is explained in textbooks in a simpler -- although sometimes less accurate -- manner, when compared to the Standard text. The use of standardese ensures the accuracy that is needed for writing compilers and checking the validity of programs. For this purpose, the Standard defines numerous specific terms that are used extensively throughout the volume; for instance, it distinguishes between a <i>template id</i> and a <i>template name</i>, whereas an average programmer simply refers to both as templates. Familiarity with these specific terms is the key to reading and interpreting the Standard correctly.</p> <h3> <a name="Heading3">Purpose and Structure of This Chapter</a></h3> <p>The purposes of this chapter are threefold. First, it presents some of the key terms that are used extensively throughout the Standard and throughout this book, for example, <i>undefined behavior</i> and <i>deprecated features</i>. (Note that topic-specific terms such as <i>argument-dependent lookup</i> and <i>trivial constructor</i> are presented in their relevant chapters rather than here.) Then, the new features that have been added to C++ -- such as <tt>bool</tt> type, new typecast operators, and <tt>mutable</tt> data members -- are discussed. Because these topics are not explained elsewhere in this book, they are presented here in detail, along with code samples. After that comes a list of other newly added features that are covered extensively in other chapters of the book. </p> <p>These topics are presented here only briefly. The intent is to provide you with an <i>executive summary</i> -- a panorama of the latest addenda to the ANSI/ISO C++ Standard -- that you can use as a checklist of topics. When reading the brief topics overview, you might come across an unfamiliar topic; in these instances, you are always referred to the chapter that discusses the topic in further detail. Finally, there is an overview the deprecated features and a list of suggested replacements for them.</p> <h2> <a name="Heading4">The Standard's Terminology</a></h2> <p>This part explains some of the key terms in the Standard that are used throughout the book. These terms appear in italics when they are presented for the first time. Note that these definitions are not exact quotations from the Standard; rather, they are interpretive definitions.</p> <h3> <a name="Heading5">Arguments and Parameters</a></h3> <p>The words <i>arguments</i> and <i>parameters</i> are often used interchangeably in the literature, although the Standard makes a clear distinction between the two. The distinction is chiefly important when discussing functions and templates.</p> <h4> Argument</h4> <p>An argument is one of the following: an expression in the comma-separated list that is bound by the parentheses in a function call; a sequence of one or more preprocessor tokens in the comma-separated list that is bound by the parentheses in a function-like macro invocation; the operand of a throw-statement or an expression, type, or template-name in the comma-separated list that is bound by the angle brackets in a template instantiation. An argument is also called an <i>actual parameter</i>.</p> <h4> Parameter</h4> <p>A parameter is one of the following: an object or reference that is declared in a function declaration or definition (or in the catch clause of an exception handler); an identifier from the comma-separated list that is bound by the parentheses immediately following the macro name in a definition of a function-like macro; or a template-parameter. A parameter is also called a <i>formal parameter.</i></p> <p>The following example demonstrates the difference between a parameter and an argument:</p> <pre><tt>void func(int n, char * pc); //n and pc are parameters</tt><tt>template <class T> class A {}; //T is a a parameter</tt><tt>int main()</tt><tt>{</tt><tt> char c;</tt><tt> char *p = &c;</tt><tt> func(5, p); //5 and p are arguments</tt><tt> A<long> a; //'long' is an argument</tt><tt> A<char> another_a; //'char' is an argument</tt><tt> return 0;</tt><tt>}</tt></pre> <h3> <a name="Heading6">Translation Unit</a></h3> <p>A <i>translation unit</i> contains a sequence of one or more declarations. The Standard uses the term <i>translation unit</i> rather than <i>source file</i> because a single translation unit can be assembled from more than a single source file: A source file and the header files that are <tt>#included</tt> in it are a single translation unit.</p> <h3> <a name="Heading7">Program</a></h3> <p>A <i>program</i> consists of one or more translation units that are linked together.</p> <h3> <a name="Heading8">Well-Formed Program</a></h3> <p>A <i>well-formed program</i> is one that is constructed according to the Standard's syntax and semantic rules and that obeys the One Definition Rule (explained in the following section). An <i>ill-formed program</i> is one that does not meet these requirements.</p> <h3> <a name="Heading9">lvalues and rvalues</a></h3> <p>An <i>object</i> is a contiguous region of storage. An <i>lvalue</i> is an expression that refers to such an object. The original definition of lvalue referred to an object that can appear on the left-hand side of an assignment. However, <tt>const</tt> objects are lvalues that cannot be used in the left-hand side of an assignment. Similarly, an expression that can appear in the right-hand side of an expression (but not in the left-hand side of an expression) is an <i>rvalue</i>. For example</p> <pre><tt> #include <string></tt><tt>using namespace std;</tt><tt>int& f();</tt><tt>void func()</tt><tt>{</tt><tt> int n;</tt><tt> char buf[3]; </tt><tt> n = 5; // n is an lvalue; 5 is an rvalue</tt><tt> buf[0] = 'a'; // buf[0] is an lvalue, 'a' is an rvalue</tt><tt> string s1 = "a", s2 = "b", s3 = "c"; // "a", "b", "c" are rvalues</tt><tt> s1 = // lvalue</tt><tt> s2 +s3; //s2 and s3 are lvalues that are implicitly converted to rvalues</tt><tt> s1 = //lvalue</tt><tt> string("z"); //temporaries are rvalues</tt><tt> int * p = new int; //p is an lvalue; 'new int' is an rvalue</tt><tt> f() = 0; //a function call that returns a reference is an lvalue</tt><tt> s1.size(); //otherwise, a function call is an rvalue expression</tt><tt>}</tt></pre> <p>An lvalue can appear in a context that requires an rvalue; in this case, the lvalue is implicitly converted to an rvalue. An rvalue cannot be converted to an lvalue. Therefore, it is possible to use every lvalue expression in the example as an rvalue, but not vice versa.</p> <h3> <a name="Heading10">Behavior Types</a></h3> <p>The Standard lists several types of program behaviors, which are detailed in the following sections.</p> <h4> Implementation-Defined Behavior</h4> <p><i>Implementation-defined behavior</i> (for a well-formed program and correct data) is one that depends on the particular implementation; it is a behavior that each implementation must document. For example, an implementation documents the size of fundamental types, whether a <tt>char</tt> can hold negative values, and whether the stack is unwound in the case of an uncaught exception. Implementation-defined behavior is also called <i>implementation-dependent behavior</i>.</p> <h4> Unspecified Behavior</h4> <p><i>Unspecified behavior</i> (for a well-formed program and correct data) is one that depends on the particular implementation. The implementation is not required to document which behavior occurs (but it is allowed to do so). For example, whether operator <tt>new</tt> calls to the Standard C library function <tt>malloc()</tt> is unspecified. Following is another example: The storage type for the temporary copy of an exception object is allocated in an unspecified way (however, it cannot be allocated on the free store).</p> <p>Implementation-defined behavior and unspecified behavior are similar. Both refer to consistent behavior that is implementation-specific. However, unspecified behavior usually refers to the underlying mechanism of the implementation, which users generally do not access directly. Implementation-dependent behavior refers to language constructs that can be used directly by users.</p> <h4> Undefined Behavior</h4> <p><i>Undefined behavior</i> is one for which the Standard imposes no requirements. This definition might sound like an understatement because undefined behavior indicates a state that generally results from an erroneous program or erroneous data. Undefined behavior can be manifested as a runtime crash or as an unstable and unreliable program state -- or it might even pass unnoticed. Writing to a buffer past its boundary, accessing an out-of-range array subscript, dereferencing a dangling pointer, and other similar operations result in undefined behavior. </p> <h4> Conclusions</h4> <p>Unspecified behavior and implementation-defined behavior are consistent -- albeit nonportable -- behaviors that are left intentionally unspecified ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -