Author: cpptutor

Concepts finally appeared in the language with the completion of C++20—I say finally as work to specify them had been going on continuously since before the release of C++11. This article attempts to explain their rationale and usage, with examples that should compile on any up-to-date C++ compiler when specifying -std=c++20 (or /std:c++20 for MSVC).

So why do we need concepts when template syntax has been available since C++98? Put simply, templates have been (successfully) used in ways that were never envisaged; however the reporting of invalid instantiations and similar errors has not kept pace. Also, the use of auto in function parameter lists gives us template syntax “invisibly”, which the novice/intermediate coder may not expect.

Continue reading “Concepts 101” →

Traits and policy classes are often used with C++ generics, but their role and purpose is often something of an enigma even to experienced C++ programmers. The definitions of these two terms overlap to some extent, and could be summarized as follows:

• Traits represent natural additional properties of a template parameter.
• Policies represent configurable behavior for generic functions and types.

In this article the example code will show use of both of these two, with type information obtained through a (specialized) traits class and functionality obtained from a (generic) policy class.

Continue reading “Designing Traits and Policy Classes” →

Functional programming (FP) is a discipline and practice of computer science where Mathematical concepts come to the fore. There are a number of popular FP languages out there, but we can stay with C++ and explore some of the themes of FP by using a subset of familiar syntax. In this article we’ll look at a number of FP concepts, such as purity, immutability and use of higher-order functions, and how they can be concisely and usefully represented in Modern C++.

1. Purity

A function is considered pure if its operation depends only upon its formal input parameters, that is not accessing any external (global) state. Global state in FP is a little like the historical Goto statement, shunned but sometimes necessary, and so is by design abstracted away as much as possible. A C++ lambda is pure if it has an empty capture clause, for example:

Continue reading “Applying Functional Programming Techniques to Modern C++” →

In the previous articles of this mini-series we’ve covered the use of custom serialization and deserialization functions to generate and interpret XML. In this article we’ll look at how to add to existing classes to give them the ability to utilize the (de-)serialization logic already written. The process is similar to before: create an in-memory model and then serialize it, or start with blank containers and then read in the data, checking for errors.

Continue reading “Designing Classes for Serialization (4)” →

In the previous articles we’ve looked at creating an in-memory XML hierarchy (or DOM), and serializing from and deserializing to this memory model. In this article we’re going to look at querying the DOM in a similar fashion to JavaScript methods such as document.getElementById() available in a browser. The scheme chosen is to overload operator [] (twice) and provide other convenience methods such as name() and numberOfChildren().

Continue reading “Designing Classes for Serialization (3)” →

The complement of serialization is deserialization, and this is typically more difficult as it requires character- or pattern-matching of the input, plus checking for erroneous input. To match a stream of XML the possibility of using std::getline() was considered, but this is too inflexible as regards whitespace. Stream input to a std::string was also considered, but again this is unsuitable as breaking all input at whitespace is not what is needed.

Continue reading “Designing Classes for Serialization (2)” →

Disclaimer: This article has nothing to do with C++. Also, I do not have a huge amount of experience with the Node.js ecosystem. This information is provided here because of the issues I had reading outdated, and often incorrect, “solutions” on forums and blogs. I hope someone finds it useful.

Continue reading “Partially Mocking an ES Module with Jest and Node.js” →

Data held in memory must be saved to a store in order to outlive the running-time of the program it belongs to. Simply dumping binary data to disk is not usually the best way, or even a practicable way, of achieving this (think security issues, endianness, 32-bits/64-bits etc.)

The terms “serialization” and its companion “deserialization” are used to describe the conversion between the in-memory model and a (usually textual) disk-file representation. As an example, consider a web-browser which reads an HTML web page (and its dependencies) from a network connection and converts (deserializes) it into a format which can be manipulated through the DOM (Document Object Model). In this article we’ll concentrate more on serialization, which is often a simpler task.

Continue reading “Designing Classes for Serialization (1)” →

In the previous article we looked at how to avoid falling into some of the pitfalls of Modern C++. For this article we’ll cover some of the more advanced areas of Modern C++, with explanations of how to avoid problems that novice programmers often encounter.

Continue reading “Common mistakes to avoid in Modern C++ (2)” →

Learning a new programming language is hard, and is especially daunting when as a novice programmer the compiler rejects pretty much every program you write the first time you try to compile it. Of course, compiler errors and warnings are important as they encourage you to write correct code and ensure that your program actually runs at all, and works as expected.

C++ has traditionally been seen as one of the harder programming languages for beginners to pick up; ideally you should already have some coding experience under your belt in (an)other programming language(s) before trying to learn Modern C++. This mini-series intends to examine the parts of C++ that novice (and more experienced) programmers sometimes fail to understand fully, leading to buggy and/or sub-optimal code.

Continue reading “Common mistakes to avoid in Modern C++ (1)” →

In this article we’re going to continue the theme of a class-designer’s toolkit, looking at adding generics (template functionality) to C++ classes. Templates have been around since C++98, and almost all C++ programmers will have used them: std::vector<int> has the type int as a parameter, itself being a specialization of a generic class. Any user-defined type can be used as a type parameter, having equal status to the built-in types.

Generic classes

Classes which are preceded by a the template keyword are automatically turned into generic classes. These classes can have any number of template parameters, we’re going to concentrate on classes having just one, this being a template type parameter. The class definition starts of as follows:

Continue reading “Generic classes in Modern C++” →

C++ has promoted class design throughout its history, and Modern C++ continues this tradition. Some new syntax has been added, while other syntax is used less often, or has been deprecated. This article aims to summarize best practice using the latest versions of the language in one place, preferring to outline the modern variants (only) without reference to historical style.

Continue reading “A Modern C++ class designer’s toolkit” →

All C++ programmers should understand the concept of “const-correctness” which is an additional form of type safety provided by the language. (C99 even incorporated this keyword and feature after C++ introduced it.) A common example of this feature is where classes provide accessors (getters/setters) to member data, with const member functions for the case where member data is logically immutable. A non-const-correct Matrix class allowing element access might look as follows:

Continue reading “Applications of C++23’s deducing ‘this’” →

The Visitor Pattern is a well-known technique of adding specific functionality to a number of possibly unrelated classes without actually modifying them significantly. If you do an online search for examples of this design pattern in C++, you may find examples with an abstract Visitor base class having a single, overloaded, pure virtual function, often called accept(). This article explores how to accomplish much the same task using compile-time polymorphism and more recent C++ syntax.

Continue reading “Visitor Pattern in Modern C++” →

As you may know, and as described in Chapter 4 of the Guide on this site, functions (and variables) may be declared constexpr in Modern C++. Functions declared with this keyword are guaranteed to be able to be called at compile-time, returning a result which can be used where a compile-time constant is needed. Importantly, these functions can also be called at with run-time-defined parameters, with the result of the function calculated at run-time with the same logic.

The new keyword consteval, added in C++20, can be used with function definitions to ensure that evaluation is performed at compile-time only. The restrictions are similar to those for constexpr functions (global state cannot be modified) with the added restriction that only constant parameter values are passed to the function when it is called. The following function definition is a valid consteval function:

Continue reading “Know ‘constexpr’? Here’s ‘consteval’, ‘constinit’” →