📄 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 14 - Concluding Remarks and Future Directions</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>
</CENTER>
<h1 align="center">14</h1>
<h1 align="center"> Concluding Remarks and Future Directions</h1>
<address>by Danny Kalev</address>
<ul>
<li><a href="#Heading3">Some of the Features that Almost Made It into the Standard</a>
<ul>
<li><a href="#Heading4">Hashed Associative Containers</a>
<li><a href="#Heading5">Default Type Arguments of Function Templates</a>
</ul>
<li><a href="#Heading6">The Evolution of C++ Compared to Other Languages</a>
<ul>
<li><a href="#Heading7">Users' Convenience</a>
<li><a href="#Heading8">"Pay as You Go"</a>
</ul>
<li><a href="#Heading9">Possible Future Additions to C++</a>
<ul>
<li><a href="#Heading10">Automatic Garbage Collection</a>
<li><a href="#Heading11">Object Persistence</a>
<li><a href="#Heading12">Support for Concurrency</a>
<li><a href="#Heading13">Extensible Member Functions</a>
<li><a href="#Heading14">Dynamically Linked Libraries</a>
<li><a href="#Heading15">Rule-Based Programming</a>
</ul>
<li><a href="#Heading16">Conclusions</a>
</ul>
<hr size=4>
<p><i>"Hey, we're done!"</i></p>
<p> <a name="Heading1">(Josee Lajoie's words right after the approval of the C++
Final Draft International Standard in the November 1997 meeting of the ANSI/ISO
C++ standardization committee in Morristown, New Jersey)Introduction</a></p>
<p>The previous chapters have told the past and the present of C++. In nearly
20 years, C++ has evolved from an experimental language into the most widely
used object-oriented programming language worldwide. The importance of standardizing
C++ cannot be overemphasized. Having the ANSI/ISO endorsement has several advantages:</p>
<ul>
<li>
<p> <b>Language stability</b> -- C++ is probably the largest programming language
in commercial use today. Learning it from scratch is a demanding and time-consuming
process. It is guaranteed that, henceforth, learning C++ is a one-time investment
rather than an iterative process.</p>
</li>
<p></p>
<li>
<p> <b>Code stability</b> -- The Standard specifies a set of deprecated features
that might become obsolete in the future. Other than that, Fully ANSI-compliant
code is guaranteed to work in the future.</p>
</li>
<p></p>
<li>
<p> <b>Manpower portability</b> -- C++ programmers can switch more easily
to different environments, projects, compilers, and companies.</p>
</li>
<p></p>
<li>
<p> <b>Easier Portability</b> -- The standard defines a common denominator
for all platforms and compiler vendors, enabling easier porting of software
across various operating systems and hardware architectures.</p>
</li>
</ul>
<p></p>
<p>The following code sample is Standard-compliant; however, some compilers will
reject it, whereas others will compile it without complaints:</p>
<pre>
<tt>#include <iostream></tt>
<tt>using namespace std;</tt>
<tt>void detect_int(size_t size)</tt>
<tt>{</tt>
<tt> switch(size)</tt>
<tt> {</tt>
<tt> case sizeof(char):</tt>
<tt> cout<<"char detected"<<endl;</tt>
<tt> break;</tt>
<tt> case sizeof(short):</tt>
<tt> cout<<"short detected"<<endl;</tt>
<tt> break;</tt>
<tt> case sizeof(int):</tt>
<tt> cout<<"int detected"<<endl;</tt>
<tt> break;</tt>
<tt> case sizeof(long):</tt>
<tt> cout<<"int detected"<<endl;</tt>
<tt> break;</tt>
<tt> }</tt>
<tt>}</tt>
</pre>
<p>On platforms that have distinct sizes for all four integral types (for example,
architectures that use 16 bits for <tt>short</tt>, 32 bits for <tt>int</tt>,
and 64 for <tt>long</tt>) this code will compile and work as expected. On other
platforms, where the size of <tt>int</tt> overlaps with the size of another
integral type, the compiler will complain on identical <tt>case</tt> labels.</p>
<p>The point to take home from this example is that the Standard does not guarantee
absolute code portability, nor does it ensure binary compatibility. However,
it facilitates software porting from one platform to another by defining a common
ground for the language, which an implementation is allowed to extend. This
practice is almost universal: Platform-specific libraries and keywords are added
to almost every C++ implementation. However, an implementation cannot alter
the specifications of the Standard (otherwise, such an implementation is not
Standard-compliant). As you will read in the following sections, allowing platform-specific
extensions is an important factor in the success of programming languages in
general; languages that have attempted to prohibit platform-specific extensions
have failed to obtain a critical mass of users due to a lack of vendor support.</p>
<h3> <a name="Heading2">Scope of this Chapter</a></h3>
<p>The previous chapters mostly focus on the hows of C++; this chapter explores
the whys. It elucidates the philosophy behind the design and evolution of C++
and compares it to the evolution of other programming languages. Some features
that almost made it into the Standard are then presented. Possible future additions
to C++, including automatic garbage collection, object persistence, and concurrency,
are discussed next. Finally, theoretical and experimental issues are discussed.
The intent is not to predict the future of C++ (there is no guarantee that any
of the features discussed here will ever become an integral part of the Standard),
but rather to give you a broader view of the challenges of language design.</p>
<h2> <a name="Heading3">Some of the Features that Almost Made It into the Standard</a></h2>
<p>The standardization of C++ lasted nine years. STL alone added at least one
more year to the original agenda. However, STL was an exception. Other features
that were proposed too late were not included in the Standard. The following
section lists two such features: hashed associative containers and default type
arguments of function templates.</p>
<h3> <a name="Heading4">Hashed Associative Containers</a></h3>
<p>The Standard Template Library provides only one type of associative container
-- the <i>sorted associative container</i>. The STL sorted associated containers
are <tt>map</tt>, <tt>multimap</tt>, <tt>set</tt>, and <tt>multiset</tt> (see
Chapter 10, "STL and Generic Programming"). However, there is another type of
associated container, the <i>hashed associative container</i>, that should really
be in the Standard Library but isn't there because it was proposed too late.
The difference between a sorted associative container and a hashed associative
container is that the former keeps the keys sorted according to some total order.
For example, in a <tt>map<string, int></tt>, the elements are sorted according
to the lexicographical order of the strings. A hashed associative container,
on the other hand, divides the keys into a number of subsets, and the association
of each key to its subset is done by a hash function. Consequently, searching
a key is confined to its subset rather than the entire key space. Searching
a hashed associative container can therefore be faster than searching a sorted
associative container under some circumstances; but unlike sorted associated
containers, the performance is less predictable. There are already vendors that
include hashed associated containers as an extension, and it is likely that
these containers will be added to the Standard in the next revision phase.</p>
<h3> <a name="Heading5">Default Type Arguments of Function Templates</a></h3>
<p>As you read in Chapter 9, "Templates," class templates can take default type
arguments. However, the Standard disallows default type arguments in function
templates. This asymmetry between class templates and function templates is
simply an unfortunate oversight that was discovered too late to be fixed. Default
type arguments of function templates will most likely be added to C++ in the
next revision of the Standard.</p>
<p> </p>
<h2> <a name="Heading6">The Evolution of C++ Compared to Other Languages</a></h2>
<p>Unlike other newer languages, C++ is not an artifact of a commercial company.
C++ does not bear the trademark sign, nor do any of its creators receive royalties
for every compiler that is sold. Thus, C++ is not subjected to the marketing
ploys and dominance battles that rage among software companies these days. Another
crucial factor that distinguishes C++ from some other "would-be perfect" programming
languages is the way in which it has been designed and extended through the
years.</p>
<p>Some of you might recall the tremendous hype that surrounded Ada in its early
days. Ada was perhaps the most presumptuous endeavor to create a language that
was free from the deficiencies of the other programming languages that existed
at that time. Ada promised to be a 100% portable language, free of subsets and
dialects. It also provided built-in support for multitasking and parameterized
types. The design of Ada lasted more than a decade, but it was a <i>design by
committee</i> process rather than the <i>design by community</i> process that
characterizes C++. The facts are known: Ada never really became the general
purpose, widely used programming language it intended to be. It is amusing to
recall today that back in 1983, when Ada was released, many believed that it
was the last third generation programming language to be created. Ironically,
C++ was making its first steps at exactly that same time. Needless to say, the
design and evolution of C++ have taken a radically different path. Other third
generation languages have appeared since 1983 and -- surely -- new third generation
languages will appear in the future. The factors that led to the failure of
Ada as a universal and general purpose programming language can serve as a lesson
in language design. </p>
<h3> <a name="Heading7">Users' Convenience</a></h3>
<p>The failure of Ada can be attributed mostly to the design by committee approach.
In addition, the prohibition of platform-specific extensions deterred vendors
from developing libraries and tools that supported the new language. It is always
surprising to learn how computer scientists and language users differ in their
views about the important features of the language. C, which was created by
programmers rather than by academia, offered convenience and efficiency at the
expense of readability and safety. For example, the capability to write statements
such as this one</p>
<pre>
<tt>if (n = v) //did the programmer mistook assignment for equality?</tt>
<tt>{</tt>
<tt>//...do something</tt>
<tt>}</tt>
</pre>
<p>has been a source of criticism. Still, it is this very feature that enables
programmers to write a complete function that consists of a single statement
such as the following:</p>
<pre>
<tt>void strcpy (char * dst, const char * src)</tt>
<tt>{</tt>
<tt> while( *dst++ = *src++ );</tt>
<tt>}</tt>
</pre>
<p>The tedium of typing long keywords is also an issue of debate. "Academic languages"
usually advocate the use of verbose statements that consist of complete keywords
-- for example, <tt>integer</tt> rather than <tt>int</tt>, <tt>character</tt>
rather than <tt>char</tt> (as in Eiffel and other similar languages), and <tt>call
func();</tt> rather than <tt>func();</tt>. Programmers, on the other hand, feel
more comfortable with truncated keywords and symbols. Look at the following:</p>
<pre>
<tt>class Derived : Base {}; //inheritance indicated by :</tt>
</pre>
<p>In other languages, inheritance is expressed by explicit keywords:</p>
<pre>
<tt>class Derived extends Base {}; //Java; full keyword indicates inheritance</tt>
</pre>
<p>C++ adopts the policy of C in this respect. Furthermore, according to Bjarne
Stroustrup, one of the principles in the design of C++ says that where there
is a choice between inconveniencing the compiler writer and annoying the programmer,
choose to inconvenience the compiler writer (<i>The Evolution of C++: Language
Design in the Marketplace of Ideas</i>, p.50). The implementations of operator
overloading, <tt>enum</tt> types, templates, default arguments, and Koenig lookup
are instances of this approach. Programmers can get along without direct language
support for these features, at the cost of inconvenience: Ordinary functions
can be used instead of overloaded operators, constants can replace <tt>enum</tt>
types, and fully qualified names can make up for the lack of Koenig lookup.
Fortunately, this is not the case in C++. Other languages, however, have adopted
the opposite approach, namely simple compiler writing at the cost of inconveniencing
the programmers. Java, for instance, does not have <tt>enum</tt> types, operator
overloading, and default arguments by design. Although these features do not
incur overhead of any kind, and no one doubts their importance and usefulness,
they make a compiler writer's work more difficult (originally, Java designers
claimed that operator overloading was an unnecessary complexity).</p>
<h3> <a name="Heading8">"Pay as You Go"</a></h3>
<p>The benefits of object-oriented programming are not free. The automatic invocation
of constructors and destructors is very handy, but it incurs additional overhead
in the speed and the size of the program. Likewise, dynamic binding and virtual
inheritance also impose performance penalties. But none of these features is
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -