Blog 5 min read

The road to the C++ fifth generation.

Share this article
The road to the C++ fifth generation.

Since its creation, C++ has evolved continuously and passed many major milestones, from C with Classes to the rise of the new standards. What’s the next step in the evolution of the C++ language? Let’s first look at how C++ has evolved over the years:

C++ first generation: C with classes

Before its initial standardization in 1998, C++ had been developed by Bjarne Stroustrup at Bell Labs since 1979, as an extension of the C language, because he wanted an efficient and flexible language similar to C.

In 1983, “C with Classes” was renamed “C++”, adding new features that included virtual functions, function name and operator overloading, references, constants, type-safe free-store memory allocation (new/delete), and 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 from “Microsoft Word 1.1”, recently released to the Computer History Museum.

c1

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, and this work became the basis for the future standard. In the 1990s OOP became very popular, and many developers adopted this paradigm. Herb Sutter, in his article, considered OOP adoption 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

Templates were introduced in 1991, and at that time only a few C++ experts were interested in the generic programming paradigm, and few publications talked about it.

Alexander Stepanov was a pioneering C++ expert who explored the possibilities of generic programming to provide a modern approach to developing C++ projects.

Here’s an interesting document entitled “Algorithm-Oriented Generic Libraries”, published in 1993 by Alexander 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.

Thanks to the effort and amazing work of Alexander Stepanov, David Musser, Meng Lee and the C++ standardization committee, the first release of the STL came out in 1994.

The STL was a breath of fresh air for C++ developers; it provided many interesting features needed to modernize C++ code, which made C++ algorithm implementations different from the C 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++ fourth generation: The new C++ standards

From 1991 to 2011 the language evolved slowly, and the evolution came from libraries like the STL and Boost. From 2011 on, many features were added to the standard: C++11, C++14, C++17 and the upcoming C++20.

Here’s a code snippet from the Folly library, which makes intensive use of the new standards.

c0

C++ fifth generation: Break with legacy C++

C++ is currently evolving very quickly. Many interesting new features are being added, and others are deprecated. Maybe it’s now time to remove some language possibilities, even if it breaks compilation.

Until now, the standardization committee has chosen not to make breaking changes to previous C++ features. However, this approach could change in the near future — indeed, this recently updated proposal discusses the stability of the language and tries to answer 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 get 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 legacy C++, to remove the possibilities inherited from C.

Share this article