B. Stroustrup - The C++ Programming Language (794319), страница 11
Текст из файла (страница 11)
Late that year, I was24Notes to the ReaderChapter 1able to present a set of language facilities supporting a coherent set of programming styles; see§1.2.1. In retrospect, I consider the introduction of constructors and destructors most significant.In the terminology of the time, ‘‘a constructor creates the execution environment for the memberfunctions and the destructor reverses that.’’ Here is the root of C++’s strategies for resource management (causing a demand for exceptions) and the key to many techniques for making user codeshort and clear. If there were other languages at the time that supported multiple constructors capable of executing general code, I didn’t (and don’t) know of them.
Destructors were new in C++.C++ was released commercially in October 1985. By then, I had added inlining (§12.1.5,§16.2.8), consts (§2.2.3, §7.5, §16.2.9), function overloading (§12.3), references (§7.7), operatoroverloading (§3.2.1.1, Chapter 18, Chapter 19), and virtual functions (§3.2.3, §20.3.2). Of thesefeatures, support for run-time polymorphism in the form of virtual functions was by far the mostcontroversial.
I knew its worth from Simula but found it impossible to convince most people in thesystems programming world of its value. Systems programmers tended to view indirect functioncalls with suspicion, and people acquainted with other languages supporting object-oriented programming had a hard time believing that virtual functions could be fast enough to be useful in systems code. Conversely, many programmers with an object-oriented background had (and many stillhave) a hard time getting used to the idea that you use virtual function calls only to express a choicethat must be made at run time.
The resistance to virtual functions may be related to a resistance tothe idea that you can get better systems through more regular structure of code supported by a programming language. Many C programmers seem convinced that what really matters is completeflexibility and careful individual crafting of every detail of a program. My view was (and is) thatwe need every bit of help we can get from languages and tools: the inherent complexity of the systems we are trying to build is always at the edge of what we can express.Much of the design of C++ was done on the blackboards of my colleagues.
In the early years,the feedback from Stu Feldman, Alexander Fraser, Steve Johnson, Brian Kernighan, Doug McIlroy,and Dennis Ritchie was invaluable.In the second half of the 1980s, I continued to add language features in response to user comments. The most important of those were templates [Stroustrup,1988] and exception handling[Koenig,1990], which were considered experimental at the time the standards effort started. In thedesign of templates, I was forced to decide among flexibility, efficiency, and early type checking.At the time, nobody knew how to simultaneously get all three, and to compete with C-style codefor demanding systems applications, I felt that I had to choose the first two properties. In retrospect, I think the choice was the correct one, and the search for better type checking of templatescontinues [Gregor,2006] [Sutton,2011] [Stroustrup,2012a].
The design of exceptions focused onmultilevel propagation of exceptions, the passing of arbitrary information to an error handler, andthe integrations between exceptions and resource management by using local objects with destructors to represent and release resources (what I clumsily called ‘‘Resource Acquisition Is Initialization’’; §13.3).I generalized C++’s inheritance mechanisms to support multiple base classes [Stroustrup,1987a]. This was called multiple inheritance and was considered difficult and controversial. Iconsidered it far less important than templates or exceptions. Multiple inheritance of abstractclasses (often called interfaces) is now universal in languages supporting static type checking andobject-oriented programming.Section 1.4.2.1Language Features and Library Facilities25The C++ language evolved hand in hand with some of the key library facilities presented in thisbook.
For example, I designed the complex [Stroustrup,1984], vector, stack, and (I/O) stream[Stroustrup,1985] classes together with the operator overloading mechanisms. The first string andlist classes were developed by Jonathan Shopiro and me as part of the same effort. Jonathan’sstring and list classes were the first to see extensive use as part of a library. The string class fromthe standard C++ library has its roots in these early efforts. The task library described in [Stroustrup,1987b] was part of the first ‘‘C with Classes’’ program ever written in 1980. I wrote it and itsassociated classes to support Simula-style simulations. Unfortunately, we had to wait until 2011(30 years!) to get concurrency support standardized and universally available (§1.4.4.2, §5.3, Chapter 41). The development of the template facility was influenced by a variety of vector, map, list,and sort templates devised by Andrew Koenig, Alex Stepanov, me, and others.C++ grew up in an environment with a multitude of established and experimental programminglanguages (e.g., Ada [Ichbiah,1979], Algol 68 [Woodward,1974], and ML [Paulson,1996]).
At thetime, I was comfortable in about 25 languages, and their influences on C++ are documented in[Stroustrup,1994] and [Stroustrup,2007]. However, the determining influences always came fromthe applications I encountered. That was a deliberate policy to have the development of C++‘‘problem driven’’ rather than imitative.1.4.3 The 1998 StandardThe explosive growth of C++ use caused some changes. Sometime during 1987, it became clearthat formal standardization of C++ was inevitable and that we needed to start preparing the groundfor a standardization effort [Stroustrup,1994].
The result was a conscious effort to maintain contactbetween implementers of C++ compilers and major users. This was done through paper and electronic mail and through face-to-face meetings at C++ conferences and elsewhere.AT&T Bell Labs made a major contribution to C++ and its wider community by allowing me toshare drafts of revised versions of the C++ reference manual with implementers and users.Because many of those people worked for companies that could be seen as competing with AT&T,the significance of this contribution should not be underestimated.
A less enlightened companycould have caused major problems of language fragmentation simply by doing nothing. As it happened, about a hundred individuals from dozens of organizations read and commented on whatbecame the generally accepted reference manual and the base document for the ANSI C++ standardization effort. Their names can be found in The Annotated C++ Reference Manual (‘‘theARM’’) [Ellis,1989]. The X3J16 committee of ANSI was convened in December 1989 at the initiative of Hewlett-Packard. In June 1991, this ANSI (American national) standardization of C++became part of an ISO (international) standardization effort for C++ and named WG21.
From1990, these joint C++ standards committees have been the main forum for the evolution of C++ andthe refinement of its definition. I served on these committees throughout. In particular, as thechairman of the working group for extensions (later called the evolution group), I was directlyresponsible for handling proposals for major changes to C++ and the addition of new language features. An initial draft standard for public review was produced in April 1995. The first ISO C++standard (ISO/IEC 14882-1998) [C++,1998] was ratified by a 22-0 national vote in 1998.
A ‘‘bugfix release’’ of this standard was issued in 2003, so you sometimes hear people refer to C++03, butthat is essentially the same language as C++98.26Notes to the ReaderChapter 11.4.3.1 Language FeaturesBy the time the ANSI and ISO standards efforts started, most major language features were in placeand documented in the ARM [Ellis,1989]. Consequently, most of the work involved refinement offeatures and their specification. The template mechanisms, in particular, benefited from muchdetailed work. Namespaces were introduced to cope with the increased size of C++ programs andthe increased number of libraries.
At the initiative of Dmitry Lenkov from Hewett-Packard, minimal facilities to use run-time type information (RTTI; Chapter 22) were introduced. I had left suchfacilities out of C++ because I had found them seriously overused in Simula. I tried to get a facilityfor optional conservative garbage collection accepted, but failed. We had to wait until the 2011standard for that.Clearly, the 1998 language was far superior in features and in particular in the detail of specification to the 1989 language. However, not all changes were improvements.
In addition to theinevitable minor mistakes, two major features were added that in retrospect should not have been:• Exception specifications provide run-time enforcement of which exceptions a function isallowed to throw. They were added at the energetic initiative of people from Sun Microsystems.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
