E-library. C universal evolution

25.03.2020

Why C ++

C ++ is currently considered the dominant language used for the development of commercial software products. V last years this dominance has slightly faltered due to similar claims from a programming language such as Java, but the pendulum of public opinion has swung in the other direction, and many programmers who abandoned C ++ for Java have recently been quick to return to their former attachment. ... In any case, these two languages are so similar that by learning one of them, you automatically master 90% of the other.

C # is new language developed by Microsoft for the networking platform. Essentially, C # is a kind of C ++, and despite a number of fundamental differences, the C # and C ++ languages coincide by about 90%. It will probably be a long time before C # becomes a serious competitor to C ++; but even if this does happen, knowledge of the C ++ language will prove to be a significant advantage.

C ++ is a general-purpose programming language. A natural area of application for him is system programming, understood in the broad sense of the word. In addition, C ++ has been successfully used in many areas of the application that go far beyond the specified scope. C ++ implementations are now found on all machines, from the humblest microcomputer to the largest supercomputer, to virtually all operating systems.

The emergence and evolution of the C ++ language

Bjarne Stroustrup is the developer of the C ++ language and the creator of the first translator. He is a Fellow at the AT&T Bell Laboratories Research Computing Center in Murray Hill, New Jersey, USA. He received his MSc in Mathematics and Computer Science from the University of Aarus (Denmark) and his PhD in Computer Science from the University of Cambridge (England). He specializes in distributed systems, operating systems, modeling and programming. Together with M.A.Ellis, he is the author of complete guidance on the C ++ language - "Guide to C ++ with notes".

Of course, C ++ owes a lot to the C language, which is preserved as a subset of it. All the means inherent in C are also preserved. low level designed to solve the most pressing problems of system programming. C, in turn, owes a lot to its predecessor, the BCPL language. The BCPL comment has been restored to C ++. Another source of inspiration was the SIMULA-67 language; it was from this that the concept of classes was borrowed (along with derived classes and virtual functions). C ++ 's ability to overload operations and the freedom to place descriptions wherever an operator may appear are reminiscent of the Algol-68 language.

Earlier versions of the language, called "C with Classes", have been in use since 1980. This language arose because the author needed to write interrupt-driven simulators. The SIMULA-67 language is ideal for this, if efficiency is not considered. The C with Classes language was used for large modeling tasks. Then the possibility of writing programs on it, for which the resources of time and memory are critical, were subjected to a rigorous test. The language lacked overloading of operations, references, virtual functions, and many other features. For the first time, C ++ went beyond the research group in which the author worked in July 1983, but then many C ++ features had not yet been developed.

The name C ++ (si plus plus), was coined by Rick Mascitti in the summer of 1983. This name reflects the evolutionary nature of changes in the language C. The designation ++ refers to the C augmentation operation. The slightly shorter name C + is a syntax error. In addition, it has already been used as the name of a completely different language. Experts in C semantics find that C ++ is worse than ++ C. The language was not named D because it is an extension of C, and it does not attempt to solve any problems by abandoning the capabilities of C. Another interesting interpretation of the name C ++ can be found in the appendix to.

Initially, C ++ was conceived so that the author and his friends did not need to program in assembly language, C or others. modern languages high level... Its main purpose is to simplify and make the programming process more pleasant for the individual programmer. Until recently, there was no paper C ++ development plan. Design, implementation and documentation went in parallel. There has never been a "C ++ Project" or a "C ++ Development Committee". Therefore, the language has evolved and continues to evolve in such a way as to overcome all the problems faced by users. The author's discussions of all problems with his friends and colleagues also serve as impulses for development.

Since the publication of the first edition of this book, the C ++ language has undergone significant changes and refinements. It mainly deals with disambiguation on overloading, binding and memory management. At the same time, minor changes were made to increase compatibility with the C language. Several generalizations and significant extensions were also introduced, such as: multiple inheritance, member functions with static and const specifications, protected members, type templates and handling special situations. All of these extensions and improvements were aimed at making C ++ a language in which libraries can be created and used. All changes are described in.

Other extensions introduced between 1985 and 1991 (such as multiple inheritance, static member functions, and pure virtual functions) have evolved from generalizations of C ++ programming experience rather than from other languages.

The extensions of the language made over these six years were primarily aimed at increasing the expressiveness of C ++ as a data abstraction language and object-oriented programming in general, and as a means for creating high-quality libraries with user-defined data types in particular.

Around 1987, it became apparent that work to standardize C ++ was imminent and that the foundation for it should begin immediately.

AT&T Bell Laboratories has been a major contributor to this work. About one hundred representatives from about 20 organizations studied and commented on what has become the modern version of the reference manual and raw materials for ANSI standardization. C ++. Finally, on the initiative of Hewlett-Packard in December 1989, the X3J16 committee was formed within ANSI. The work on C ++ standardization in ANSI (American Standard) is expected to be part of the work on standardization by ISO (International Organization for Standardization).

C ++ evolved concurrently with the development of some fundamental classes.

The book focuses on the overall design goals, the evolution of the language from the original C with Classes project to state of the art and a description of the development of linguistic concepts. Also Stroustrup showed in detail in the book the connection between C ++ and the Simula language.

The idea to write an article on the history of C ++ was proposed to Stroustrup at the second ACM conference on the history of programming languages in 1993 (ACM HOPL -2). The interest of others prompted him to take on more serious work, and by 1994 a whole book had been written.

Write a review on Design and Evolution of C ++

Notes (edit)

Excerpt from the Design and Evolution of C ++

Rostov stopped his horse for a moment on a hillock to examine what was being done; but no matter how he strained his attention, he could neither understand nor make out what was being done: some people were moving there in the smoke, some canvases of troops were moving in front and behind; but why? who? where? it was impossible to understand. This sight and these sounds not only did not excite in him some dull or timid feeling, but, on the contrary, gave him energy and decisiveness.
"Well, more, give more!" - he turned mentally to these sounds and again began to gallop along the line, penetrating further and further into the area of the troops that had already entered into action.
“I don’t know how it will be there, but everything will be fine!” thought Rostov.
Having passed some Austrian troops, Rostov noticed that the next part of the line (it was the guard) had already entered into action.
"All the better! I'll take a closer look, ”he thought.
He drove almost along the front line. Several horsemen galloped towards him. These were our Life Lancers, who were returning from the attack in frustrated ranks. Rostov passed them, involuntarily noticed one of them covered in blood, and galloped on.
"I don't care about this!" he thought. No sooner had he traveled a few hundred paces after that, when to his left, across the course of the field, a huge mass of cavalrymen on black horses, in white shiny uniforms, appeared at a trot straight at him. Rostov put his horse at full gallop in order to get out of the way from these cavalrymen, and he would have left them if they were still walking with the same gait, but they kept adding speed, so that some horses were already galloping. Rostov heard their footfalls and the clatter of their weapons more and more, and their horses, figures and even faces became more visible. These were our cavalry guards, marching into the attack on the French cavalry, which was advancing towards them.
The cavalry guards galloped, but still holding their horses. Rostov already saw their faces and heard the command: "march, march!" pronounced by the officer who released his blood horse at full swing. Rostov, fearing to be crushed or lured into an attack on the French, galloped along the front, which was the urine of his horse, and still did not have time to pass them.
The extreme cavalry guard, a huge pockmarked man, frowned angrily when he saw Rostov in front of him, whom he inevitably had to face. This cavalry guard would certainly have knocked Rostov and his Bedouin off his feet (Rostov himself seemed so small and weak in comparison with these huge people and horses), if he had not guessed to swing a whip in the eyes of a horse of a guard. The black, heavy, five-shovel horse dashed, ears back; but the pockmarked cavalry guard thrust huge spurs into her flanks with a swing, and the horse, swinging its tail and stretching its neck, rushed even faster. As soon as the cavalry guards passed Rostov, he heard their cry: "Hurray!" and looking back he saw that their front ranks were mingling with strangers, probably French, cavalrymen in red epaulettes. Further it was impossible to see anything, because immediately after that, guns began to shoot from somewhere, and everything was covered with smoke. Bjorn Stroustrup - Design and Evolution of C ++.
Publisher: DMK Press, Peter, 2006
ISBN 5-469-01217-4
Pages: 445

Quality: 300 dpi

Format: djvu

Size: 2.9 Mb

From the publisher

Description key ideas will give the novice user the foundation on which he later builds his understanding of all the details of the language. An experienced programmer will find a discussion of fundamental design issues here that will allow him to better understand the language with which he is working.

Design and evolution of C ++ - Stroustrup B. - 2006.

The book, written by the creator of the C ++ language, Bjarne Stroustrup, describes the design and development process of the C ++ programming language.
It outlines the goals, principles, and practical constraints that have influenced the structure and appearance of C ++, and discusses the design of features recently added to the language: templates, exceptions, runtime type identification, and namespaces. The author analyzes the decisions made in the course of working on the language and demonstrates how to correctly apply a "real object-oriented programming language".
The book is conveniently organized, instructive, and humorous. The description of the key ideas will give the novice user the foundation on which he later builds his understanding of all the details of the language. An experienced programmer will find a discussion of fundamental design issues here that will allow him to better understand the language with which he is working.

Foreword
Acknowledgments
A message to the reader
Part I
Chapter 1. Background to C ++
1.1. Simula and Distributed Systems
1.2. C language and systems programming
1.3. A little about the author of the book
Chapter 2. C language with Classes
2.1. Birth C with Classes
2.2. Overview of language features
2.3. Classes
2.4. Efficiency of execution
2.4.1. Embedding
2.5. Layout model
2.5.1. Simple implementations
2.5.2. Object placement model in memory
2.6. Static type checking
2.6.1. Narrowing conversions
2.6.2.0 usefulness of warnings
2.7. Why C?
2.8 Syntax problems
2.8.1. C declaration syntax
2.8.2. Structure tags and type names
2.8.3. Importance of syntax
2.9. Derived classes
2.9.1. Polymorphism without virtual functions
2.9.2. Container classes without templates
2.9.3. Object placement model in memory
2.9.4. Retrospective
2.10. Defense model
2.11. Execution time guarantees
2.11.1. Constructors and destructors.
2.11.2. Memory allocation and constructors.
2.11.3. Call and return functions.
2.12. Less essential funds.
2.12.1. Overloading the assignment operator
2.12.2. Default arguments
2.13. What is not implemented in C with Classes
2.14. Working environment.
Chapter 3. The birth of C ++
3.1. From C with Classes to C ++.
3.2. C ++ goals
3.3. Cfront compiler
3.3.1. Generating C code
3.3.2. Parsing C ++
3.3.3. Layout problems
3.3.4. Versions of Cfront.
3.4. Language features
3.5. Virtual functions
3.5.1. Object placement model in memory
3.5.2. Replacing and finding a suitable virtual function
3.5.3. Hiding members of the base class.
3.6. Overload
3.6.1. Overload basics.
3.6.2. Member fuctions and friendly functions
3.6.3. Operator functions
3.6.4. Overload and efficiency
3.6.5. Language change and new operators
3.7. Links
3.7.1. Lvalue and Rvalue
3.8. Constants.
3.9. Memory management
3.10. Type control
3.11. Minor features
3.11.1. Comments (1)
3.11.2. Notation for constructors
3.11.3. Qualification.
3.11.4. Initializing global objects
3.11.5. Announcement suggestions
3.12. C and C ++ languages.
3.13. Language design tools
3.14. Book "The C ++ Programming Language".
3.15. Article "Whatis?"
Chapter 4. C ++ Design Rules
4.1. Rules and principles
4.2. General rules.
4.3. Design support rules,
4.4. Technical rules.,
4.5. Low-level programming support rules
4.6. Final word
Chapter 5. Timeline 1985-1993
5.1. Introduction
5.2. Version 2.0
5.2.1. Opportunity overview.
5.3. Annotated reference guide.
5.3.1. ARM Review
5.4. ANSI and ISO standardization
5.4.1. Opportunity overview.
Chapter 6. Standardization.
6.1. What is a standard? ...
6.1.1. Details of implementation
6.1.2. Realism test
6.2. Committee work.
6.2.1. Mutters on the committee
6.3. How the work was carried out.
6.3.1. Name resolution
6.3.2. The burden of life of objects
6.4. Extensions.
6.4.1. Criteria for consideration of proposals
6.4.2. Current state of affairs
6.4.3. Problems with useful extensions
6.4.4. Logical consistency,
6.5. Examples of suggested extensions,
6.5.1. Named arguments,
6.5.2. Limited pointers
6.5.3. Character sets.
Chapter 7. Interest and use.
7.1. Growing interest in C ++
7.1.1. Lack of marketing C ++
7.1.2. Conferences.
7.1.3 Magazines and books.
7.1.4. Compilers
7.1.5. Tools and programming environments
7.2. Teaching and learning C ++.
7.3. Users and Applications
7.3.1. First users
7.3.2. Areas of application of C ++.
7L. Commercial competition.
7.4.1. Traditional languages
7.4.2. Modern languages.
7.4.3. How to compete.
Chapter 8. Libraries
8.1. Introduction.
8.2. Designing a C ++ Library
8.2.1. Library design alternatives.
8.2.2. Language tools and library building.
8.2.3. How to work with various libraries
8.3. Early libraries.
8.3.1. Streaming I / O library.
8.3.2. Concurrency support
8.4. Other Libraries
8.4.1. Base Libraries
8.4.2. Stability and base of bottom,
8.4.3. Libraries for numerical calculations
8.4.4. Specialized libraries
8.5. Standard library
Chapter 9. Prospects for the development of the C ++ language.
9.1. Introduction.
9.2. Assessment of the distance traveled.
9.2.1. Have you met the main goals of C ++? ...
9.2.2. Is C ++ a Logically Sequential Language?
9.2.3. The main flaw in the language
9.3. Is it just a bridge?
9.3.1. The bridge is needed for a long time
9.3.2. If C ++ is the answer, what is the question? ...
9.4. What can make C ++ more efficient
9.4.1. Stability and standards.
9.4.2. Training and techniques.
9.4.3. Systemic issues.
9.4.4. Outside files and syntax
9.4.5. Summing up and perspectives
Part II
Chapter 10. Memory management
10.1. Introduction
10.2. Separating memory allocation and initialization.
10.3. Allocating memory for an array
10.4. Placement of an object in memory.,
10.5. Memory deallocation problems.
10.5.1. Freeing memory for arrays
10.6. Out of memory
10.7. Automatic garbage collection
10.7.1. Optional garbage collector
10.7.2. What should an optional garbage collector look like?
Chapter 11. Overload
11.1. Introduction
1 1.2. Overload resolution.
11.2.1. Detailed Resolution
11.2.2. Ambiguity management
11.2.3. Null pointer.
11.2.4. Overload keyword
11.3 Type-Safe Layout
11.3.1. Overloading and linking
11.3.2. Implementation of layout in C ++.
11.3.3. Analysis of the distance traveled
11.4. Creating and copying objects
11.4.1. Copy admissibility control.
11.4.2. Memory allocation management
11.4.3. Inheritance management
11.4.4. Membership copying.
11.5. Convenience of notation.
11.5.1. Smart pointers.
11.5.2. Smart links
1 1.5.3. Overloading the increment and decrement operators
11.5.4. Overload -> *
11.5.5. Overloading the comma operator
11.6. Adding operators to C ++
11.6.1. Exponentiation operator
11.6.2. User-defined operators.
11.6.3. Compound operators.
11.7. Enumerations.
11.7.1 Enumeration-based overloading
11.7.2 The Booleon Type
Chapter 12. Multiple inheritance.
12.1 Introduction
12.2. Base classes.
12.3. Virtual base classes.
12.3.1. Virtual base classes and virtual functions
12.4. Object placement model in memory.
12.4.1. Placement of a virtual base class object in memory
12.4.2. Virtual base classes and type casting.
12.5. Combination of methods.
12.6. Controversy about multiple inheritance
12.7. Delegation
12.8. Renaming
12.9. Member and base class initializers
Chapter 13. Clarification of the class concept
13.1 Introduction
13.2. Abstract classes
13.2.1. Abstract classes and error handling
13.2.2. Abstract types
13.2.3. Syntax.
13.2.4. Virtual functions and constructors.
13.3. Constant member functions
13.3.1. Ignoring cons "when casting
13.3.2. Clarifying the definition of const
13.3.3. The mutable keyword and type casting.
13.4. Static member functions.
13.5. Nested classes
13.6. The inherited keyword
13.7. Loosening of substitution rules,
13.7.1. Relaxation of the rules of arguments,
13.8. Multimethods.,
13.8.1. When there are no multimethods.
13.9. Protected members
13.10. Improved code generation
13.11. Member function pointers.
Chapter 14. Cast.
14.1. Large extensions
14.2. Runtime Type Identification
14.2.1. Why is the RTTI mechanism needed?
14.2.2. Dynamic_cast operator
14.2.3. Correct and Incorrect Use of RTTI
14.2.4. Why give "dangerous drugs"
14.2.5. Typeid () operator
14.2.6. Object placement model in memory,
14.2.7. Simple I / O of objects,
14.2.8. Other options
14.3. New notation for typecasting
14.3.1. Disadvantages of old type casts
14.3.2. Static_cast operator.
14.3.3. Reinterpret_cast operator,
14.3.4. Const_cast operator.
14.3.5. Benefits of new type casts
Chapter 15. Templates
15.1 Introduction
15.2. Why templates are needed.
15.3. Class templates
15.3.1. Non-Type Template Arguments
15L. Restrictions on template arguments.
15.4.1. Limitations due to inheritance.
15.4.2. Limitations through use
15.5. Eliminate code duplication
15.6. Function templates
15.6.1. Derivation of function template arguments.
15.6.2. Setting the function template arguments.
15.6.3. Overloading a function template
15.7. Syntax
15.8. Composition methods
15.8.1. Presentation of the implementation strategy
15.8.2. Representation of order relations
15.9. Relationships between class templates.
15.9.1. Inheritance relationships
15.9.2. Transformations
15.9.3. Member templates.
15.10. Instantiating templates
15.10.1. Explicit instantiation.
15.10.2. The point of instantiation.
15.10.3. Specialization.
15.10.4. Finding Template Definitions
15.11. Consequences of introducing templates
15.11.1. Decoupling implementation from interface
15.11.2. Flexibility and efficiency
15.11.3. Impact on other C ++ components.
Chapter 16. Exception Handling
16.1 Introduction
16.2. Objectives and Assumptions
16.3. Syntax
16.4. Grouping.
16.5. Resource management
16.5.1. Errors in constructors
16.6. Resume or termination?
16.6.1. Workarounds for implementing renewal.
16.7. Asynchronous events
16.8. Spread over multiple levels
16.9. Static check
16.9.1. Implementation issues.
16.10. Invariants
Chapter 17. Namespaces
17.1 Introduction
17.2. What are namespaces for
17.2.1. Workarounds
17.3. What would be the best solution?
17.4. Solution: namespaces.
17.4.1. Opinions about namespaces
17.4.2. Namespace injection
17.4.3. Namespace aliases
17.4.4. Using namespaces for version control
17.4.5. Technical details
17.5. Classes and namespaces
17.5.1. Derived classes.
17.5.2. Using base classes.
17.5.3. Eliminate static global declarations
17.6. Compatible with C
Chapter 18. C Preprocessor
Alphabetical index.

Chapter 10. Memory Management

10.1. Introduction
10.2. Decoupling memory allocation and initialization
10.3. Allocating memory for an array
10.4. Placement of an object in memory
10.5. Memory deallocation problems

10.5.1. Freeing memory for arrays
10.6. Out of memory
10.7. Automatic garbage collection

10.7.1. Optional garbage collector
10.7.2. What should an optional garbage collector look like?

Chapter 11. Overload

11.1. Introduction
11.2. Overload resolution

11.2.1. Detailed Resolution
11.2.2. Ambiguity management
11.2.3. Null pointer
11.2.4. Overload keyword
11.3. Type-safe layout

11.3.1. Overloading and linking
11.3.2. Implementing layout in C ++
11.3.3. Analysis of the distance traveled
11.4. Creating and copying objects

11.4.1. Copy Allowance Control
11.4.2. Memory allocation management
11.4.3. Inheritance management
11.4.4. Memberwise copying
11.5. Convenience of notation

11.5.1. Smart pointers
11.5.2. Smart links
11.5.3. Overloading the increment and decrement operators
11.5.4. Overload -> *
11.5.5. Overloading the comma operator
11.6. Adding operators to C ++

11.6.1. Exponentiation operator
11.6.2. User-defined operators
11.6.3. Compound Operators
11.7. Enumerations

11.7.1 Enumeration-based overloading
11.7.2. Boolean type

Chapter 12. Multiple inheritance

12.1. Introduction
12.2. Base Classes
12.3. Virtual base classes

12.3.1. Virtual base classes and virtual functions
12.4. Object placement model in memory

12.4.1. Placement of a virtual base class object in memory
12.4.2. Virtual base classes and type casting
12.5. Combining methods
12.6. The multiple inheritance controversy
12.7. Delegation
12.8. Renaming
12.9. Member and base class initializers

Chapter 13. Clarification of the class concept

13.1 Introduction
13.2. Abstract classes

13.2.1. Abstract classes and error handling
13.2.2. Abstract types
13.2.3. Syntax
13.2.4. Virtual functions and constructors
13.3. Constant member functions

13.3.1. Ignoring const when casting types
13.3.2. Clarifying the definition of const
13.3.3. The mutable keyword and type casting
13.4. Static member functions
13.5. Nested classes
13.6. The inherited keyword
13.7. Loosening of substitution rules

13.7.1. Relaxing the rules of arguments
13.8. Multimethods

13.8.1. When there are no multimethods
13.9. Protected members
13.10. Improved code generation
13.11. Member function pointers

Chapter 14. Typecasting

14.1. Large extensions
14.2. Runtime Type Identification

14.2.1. Why is the RTTI mechanism needed?
14.2.2. Dynamic_cast operator
14.2.3. Correct and Incorrect Use of RTTI
14.2.4. Why give "" dangerous drugs ""
14.2.5. Typeid () operator
14.2.6. Object placement model in memory
14.2.7. Simple object I / O
14.2.8. Other options
14.3. New notation for typecasting

14.3.1. Disadvantages of old type casts
14.3.2. Static_cast operator
14.3.3. Reinterpret_cast operator
14.3.4. Const_cast operator
14.3.5. Benefits of new casts

Chapter 15. Templates

15.1. Introduction
15.2. Why templates are needed
15.3. Class templates

15.3.1. Non-Type Template Arguments
15.4. Restrictions on Template Arguments

15.4.1. Limitations due to inheritance
15.4.2. Limitations through use
15.5. Eliminate code duplication
15.6. Function templates

15.6.1. Deriving function template arguments
15.6.2. Setting function template arguments
15.6.3. Overloading a function template
15.7. Syntax
15.8. Composition methods

15.8.1. Presentation of the implementation strategy
15.8.2. Representation of order relations
15.9. Relationships between class templates

15.9.1. Inheritance relationships
15.9.2. Transformations
15.9.3. Member templates
15.10. Instantiating templates

15.10.1. Explicit instantiation
15.10.2. Point of instantiation
15.10.3. Specialization
15.10.4. Finding Template Definitions
15.11. Consequences of introducing templates

15.11.1. Decoupling implementation from interface
15.11.2. Flexibility and efficiency
15.11.3. Impact on other C ++ components

Chapter 16. Handling Exceptions