Chapter 6 Modularization

Listing 6-38.  The Module Interface Unit of the financialmath Module

export module financialmath;

export namespace financialmath {

long double calculateCompoundedInterest(const long double initialCapital, const long double rate,

const unsigned short term);

}

Listing 6-39.  The Module Implementation Unit of the financialmath Module

module;

#include <cmath> module financialmath;

namespace financialmath {

long double calculateCompoundedInterest(const long double initialCapital, const long double rate,

const unsigned short term) {

return initialCapital * pow((1.0 + rate / 100.0), term);

}

}

Of course, this division also has some disadvantages. As with the well-known separation of header and source code files, the separation of a module into an interface and implementation unit violates the DRY principle (see Chapter 3).

Okay, that was modules in a nutshell. There is much more to tell about modules, such as module partitions, or the creation of submodules, but that would go far beyond the scope of this book. Now let’s take a look at what this new concept means to clean code developers, and what impact it has on the architecture of a software.

The Impact of Modules

The most frequently mentioned advantage of C++20 modules is that with this new language feature, the compilation speed is increased. This is basically true and is also good news, but it is only a very small, and I think not the most interesting aspect.

290

Chapter 6 Modularization

I believe that C++20 modules will have a greater impact on the whole C++ ecosystem than any other feature added after C++98. Modules have the potential to reduce—and eventually eliminate—the preprocessor and to get rid of most or all C-style macros. They change how C++ projects are compiled, i.e., they will have an impact on build systems and CI/CD tool chains. And even if software architecture is much more than just defining components and structuring the code, modules also have an impact on how C++ projects are organized and structured.

Modules offer true encapsulation, i.e. the information hiding principle that we know from Chapter 3 is greatly supported. You can explicitly specify a module’s interface that should be exported; thus, you can define what is publicly accessible and what not. We can bundle a bunch of modules into a bigger module, this enables you to build a logical structure, for instance, a hierarchical breakdown structure even on component level as depicted in Figure 6-1. All these features can significantly increase the understandability, maintainability, and extensibility of large and complex C++ development projects. And from a clean code developer’s point of view, we can get rid of a lot of ugly, C-style macros.

291

CHAPTER 7

Functional Programming

For the past several years, a programming paradigm has experienced a renaissance that’s often viewed as a kind of counterdraft to object orientation. We are talking about functional programming.

One of the first functional programming languages was Lisp (The uppercase “LISP” is an older spelling, because the name of the language is an abbreviation for “LISt Processing”). It was designed by the American computer scientist and cognitive scientist John McCarthy in 1958 at the Massachusetts Institute of Technology (MIT). McCarthy also coined the term “artificial intelligence” (AI), and he used Lisp as the programming language for AI applications. Lisp is based on the so-called Lambda Calculus (λ calculus), a formal model that was introduced in the 1930s by the American mathematician Alonzo Church.

THE LAMBDA CALCULUS

It is difficult to find a painless introduction into the lambda calculus. Many essays on this subject are scientifically written and require a good knowledge of mathematics and logic. I will not try to explain the lambda calculus here, because it is not the main focus of this book. But you can find countless explanations on the Internet; just use the search engine of your trust, and you will get hundreds of hits.

The lambda calculus can be regarded as the simplest and smallest programming language possible. It consists of two parts: one single function definition scheme and one single transformation rule. These two components are sufficient to create a generic model for the formal description of functional programming languages, like LISP, Haskell, Clojure, etc.

293

© Stephan Roth 2021

S. Roth, Clean C++20, https://doi.org/10.1007/978-1-4842-5949-8_7

Chapter 7 Functional Programming

In fact, Lisp is a family of computer programming languages. Various dialects of Lisp have emerged. For instance, everyone who has used a member of the famous Emacs text editor family, such as GNU Emacs or X Emacs, knows the dialect Emacs Lisp that is used as a scripting language for extension and automation.

Noteworthy functional programming languages developed using Lisp include:

•\ Scheme: A Lisp dialect with static binding that was developed in the 1970s at the MIT Artificial Intelligence Laboratory (AI Lab).

•\ Miranda: The first purely and lazy functional language that was commercially supported.

•\ Haskell: A general-purpose, purely functional programming language named after the American logician and mathematician Haskell Brooks Curry.

•\ Erlang: Developed by the Swedish telecommunication company Ericsson with a main focus on building massive scalable and high reliable real-time software systems.

•\ F# (pronounced F sharp): A multiparadigm programming language and a member of the Microsoft .NET Framework. The main paradigm of F# is functional programming, but it allows the developer to switch to the imperative/object-oriented world of the .NET ecosystem.

•\ Clojure: A modern dialect of the Lisp programming language created by Rich Hickey. Clojure is purely functional and runs on the Java virtual machine and the Common Language Runtime (CLR; the runtime environment of the Microsoft .NET Framework).

Functional programming languages are still not as widely used as their imperative relatives, such as the object-oriented ones, but they are increasing in dissemination. Examples are JavaScript and Scala, which admittedly are both multiparadigm languages (i.e., they are not purely functional). They have both become increasingly popular, especially in web development, in part due to their functional programming capabilities.

This is reason enough to dive deeper into this topic and to explore what this style of programming is all about, as well as discuss what modern C++ has to offer in this direction.

294