📄 index.html
字号:
<!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>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -