[ Pobierz całość w formacie PDF ]
adhere.
Copyright 1999, Macmillan Computer Publishing. All rights reserved.
ANSI/ISO C++ Professional
Programmer's Handbook
14
Concluding Remarks and Future
Directions
by Danny Kalev
" Some of the Features that Almost Made It into the Standard
o Hashed Associative Containers
o Default Type Arguments of Function Templates
" The Evolution of C++ Compared to Other Languages
o Users' Convenience
o "Pay as You Go"
" Possible Future Additions to C++
o Automatic Garbage Collection
o Object Persistence
o Support for Concurrency
o Extensible Member Functions
o Dynamically Linked Libraries
o Rule-Based Programming
" Conclusions
"Hey, we're done!"
(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
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:
" Language stability -- 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.
" Code stability -- 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.
" Manpower portability -- C++ programmers can switch more easily to different
environments, projects, compilers, and companies.
" Easier Portability -- The standard defines a common denominator for all
platforms and compiler vendors, enabling easier porting of software across
various operating systems and hardware architectures.
The following code sample is Standard-compliant; however, some compilers will reject
it, whereas others will compile it without complaints:
#include
using namespace std;
void detect_int(size_t size)
{
switch(size)
{
case sizeof(char):
cout
break;
case sizeof(short):
cout
break;
case sizeof(int):
cout
break;
case sizeof(long):
cout
break;
}
}
On platforms that have distinct sizes for all four integral types (for example, architectures
that use 16 bits for short, 32 bits for int, and 64 for long) this code will compile and
work as expected. On other platforms, where the size of int overlaps with the size of
another integral type, the compiler will complain on identical case labels.
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.
Scope of this Chapter
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.
Some of the Features that Almost Made It into the
Standard
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.
Hashed Associative Containers
The Standard Template Library provides only one type of associative container -- the
sorted associative container. The STL sorted associated containers are map, multimap,
set, and multiset (see Chapter 10, "STL and Generic Programming"). However, there
is another type of associated container, the hashed associative container, 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
[ Pobierz całość w formacie PDF ]