📄 ch14.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 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 forced on the programmer. Pure procedural C++ code (legacy C code that is ported ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -