Since its creation, C++ evolved continuously and it passed many major milestones from the C with classes to the rise of the new standards. What’s the next step to evolve the C++ language? Let’s first discover the evolution of C++ over years:
C++ first generation: C with classes
Before the initial standardization in 1998, C++ was developed by Bjarne Stroustrup at Bell Labs since 1979, as an extension of the C language as he wanted an efficient and flexible language similar to C
In 1983, “C with Classes” was renamed to “C++”, adding new features that included virtual functions, function name and operator overloading, references, constants, type-safe free-store memory allocation (new/delete), improved type checking.
Here’s a snippet of the code from the first generation:
WriteFraction(n) long n;
{
unsigned short i, low, digit; unsigned long k;
putchar(n < 0 ? '-' : ' '); n = abs(n);
putchar((n>>fractionBits) + '0'); putchar('.');
low = k = n << (longBits-fractionBits); /* align octal point at left */
k >>= 4; /* shift to make room for a decimal digit */
for (i=1; i<=8; ++i)
{
digit = (k *= 10L) >> (longBits-4);
low = (low & 0xf) * 10;
k += ((unsigned long) (low>>4)) - ((unsigned long) digit << (longBits-4));
putchar(digit+'0');
}
}
Here’s another code snippet with “Microsoft Word 1.1” released recently in the Computer History Museum.
C++ second generation: OOP revolution
In 1989, C++ 2.0 was released, followed by the updated second edition of The C++ Programming Language in 1991.New features in 2.0 included multiple inheritance, abstract classes, static member functions, const member functions, and protected members. In 1990, The Annotated C++ Reference Manual was published. This work became the basis for the future standard. In the 1990s the OOP become very popular and many developers adopted this paradigm. Herb Sutter in his article considered the OOP adoption as a revolution :
Remember that people have been doing object-oriented programming since at least the days of Simula in the late 1960s. But OO didn’t become a revolution, and dominant in the mainstream, until the 1990s. Why then? The reason the revolution happened was primarily that our industry was driven by requirements to write larger and larger systems that solved larger and larger problems and exploited the greater and greater CPU and storage resources that were becoming available. OOP’s strengths in abstraction and dependency management made it a necessity for achieving large-scale software development that is economical, reliable, and repeatable.
C++ third generation: Generics and Meta Programming
The templates were introduced in 1991 and at this time only a few C++ experts are interested in the generic programming paradigm and few publications talked about it.
Alexandre Stephanov was a pioneer C++ expert who try to explore the generic programming possibilities to provide a modern approach to develop the C++ projects.
Here’s an interesting document entitled “Algorithm-Oriented Generic Libraries” published in 1993 by Alexandre A Stepanov and David R Summer.
Here’s the motivation from the document as explained by the authors:
We outline an approach to construction of software libraries in which generic algorithms (algorithmic abstractions) play a more central role than in conventional software library technology or in the object-oriented programming paradigm. Our approach is to consider algorithms first, decide what types and access operations they need for efficient execution, and regard the types and operations as formal parameters that can be instantiated in many different ways, as long as the actual parameters satisfy the assumptions on which the correctness and efficiency of the algorithms are based. The means by which instantiation is carried out is language dependent; in the C + + examples in this paper, we instantiate generic algorithms by constructing classes that define the needed types and access operations. By use of such compile-time techniques and careful attention to algorithmic issues, it is possible to construct software components of broad utility with no sacrifice of efficiency.
The effort and amazing work of Alexandre Stephanove , David Musser, Meng Lee and the C++ standardization committee, a first release version of STL was released in 1994.
The STL was a breath of fresh air to the C++ developers, it provided many interesting features needed to modernize the C++ code which makes the C++ algorithms implementations different to the C implementations ones.
In 1998 a proposal for a C++ Library Repository Web Site was posted by Beman G. Dawes to develop Boost.
Boost is a set of libraries for the C++ programming language that provides support for tasks and structures such as linear algebra, pseudorandom number generation, multithreading, image processing, regular expressions, and unit testing. It contains over eighty individual libraries.
C++ forth generation: The new C++ standards
From 1991 to 2011 the language evolved slowly and the evolution comes from the libraries like STL and Boost. From 2011 many features were added to the standard, we can enumerate C++11, C++14, C++17 and the coming C++20.
Here’s a code snippet from the folly library that uses intensively the new standards.
C++ fifth generation: Break with the legacy C++
Currently C++ evolve very quickly. Many new interesting features are added and others where deprecated. It’s now time to remove some language possibilities and if it’s break the compilation.
Until now the standadisation comitee chose to not do a breaking change in the previous C++ features. However this approach could change in the near future. Indeed from this proposal updated recently that discuss the stability of the language and try to answer to these questions:
- Is C++ a language of exciting new features?
- Is C++ a language known for great stability over a long period?
- Do we believe that upgrading to a new language version should be effortless?
- If so, how do we reconcile those effortless upgrades with a practical need to evolve the language?
- If we instead prioritize stability over all else, are we bound to move slowly – only making a change when we are certain it is correct and will never need future fixes?
From the proposal we have this suggestion:
The Committee should be willing to consider the design / quality of proposals even if they may cause a change in behavior or failure to compile for existing code.
Maybe the fifth generation will be the break with the legacy C++ to remove the possibilities inherited from C.
