The code examples in this chapter can be found in the GitHub repository https://github.com/PacktPublishing/Debunking-CPP-Myths in the ch1 folder. The code uses doctest (https://github.com/doctest/doctest) as a testing library, g++ and make for compilation, and targets C++ 20. You will also need valgrind (https://valgrind.org/) to check for memory leaks.

The beginnings of C++ saw it as an extension to C, only using the new paradigm, object-oriented programming (OOP), thus promising to solve the many problems of growing code bases. This initial version of C++ is unforgiving; you, the programmer, had to deeply understand how memory allocation and release works and how pointer arithmetic works, as well as guard against a myriad of subtleties that you’d be likely to miss and that usually ended up in an unhelpful error message. It didn’t help that the prevalent cultural zeitgeist of programmers back then was that a real programmer had to know all the intricacies of CPUs, RAM, various assembly languages, OS workings, and compilers. It also didn’t help that the standardization committee did almost nothing to reduce the possibility of such errors for decades. No wonder the fame of the language is following it almost 40 years later. My experience learning it only helps to understand the struggles to learn the language back then.

I had my first touches with C++ during my polytechnics studies, in the 90s. They had left me both intrigued and puzzled. I understood the power of the language, while it was actively fighting against me – or that’s how I perceived it. I had to struggle to write code that worked. I was not yet familiar with STL, which was yet to gain notoriety as part of the standard, so most of my first C++ programs dealt with pointer usage. A common question at C++ exams was about differentiating between an array of pointers and a pointer to an array. I can only imagine how helpful the complexities of the language were for building exam questions!

For the record, see here the difference between pointer to array and array of pointers, a common exam question for C++:

int(*pointerToArrayOf10Numbers)[10];

int *arrayOfTenPointers[10]

I continued learning C++ through practice and from books I could find before the internet would make the knowledge available to everyone. But the biggest jump in my understanding of the language was a project I worked on around the 2000s. The project lead, a very technical Belgian man, set for us very clear guidelines and a process we had to follow to get the best C++ code possible. This need for excellence did not come simply from his desires but from the project needs: we were building a NoSQL database engine many years before they would be given this label.

For this project, I had to study and know all the rules from the two seminal books on C++: Effective C++ and More Effective C++ by Scott Meyers. The two books document in total 90 guidelines for C++ programmers, ranging from issues of resource initialization and release to minute ways to improve performance, inheritance, exception handling, and so on. This is also when I started using STL extensively, although the standard library was much more limited in scope than it is today.

This newly acquired knowledge made my C++ programs more reliable and made me more productive. An important contributing factor was the process we used in synergy with the wisdom of the two books. We wrote unit tests, we performed design and code reviews, and we carefully crafted our code knowing that it would be dissected by a colleague before getting accepted in the code base. This made our code quasi-bug-free and helped us implement complex features with high performance in a reasonable time.

However, the language was still fighting against us. We knew how to write good C++ code, only it required a level of attention and care that inevitably slowed us down. Mastering C++ was not enough; the language had to give something back.

After this project, I left the C++ world and learned C# and managed C++, Java, PHP, Python, Haskell, JavaScript, and Groovy, to limit myself to those languages I’d used for professional programming. While every programming language offered higher abstractions and fewer headaches compared to C++, I still had nostalgia for my formative years in programming. The fact that I knew C++ and all the intricacies of memory management gave me a deep understanding of the inner workings of these other languages, allowing me to use them to their fullest. Haskell proved to be very familiar to me since it was closely mapping the meta-programming techniques I’d learned from the seminal book by Andrei Alexandrescu, Modern C++ Design. C++ was living on in my mind, not only as the first programming language I used professionally but also as a foundation for every other language I’ve used since.

To my delight, around 2010, the news came that the C++ standardization committee was finally making bold and frequent changes to the language. The last C++ standard had been for many years C++ 98; suddenly we were seeing a new version every three years. This rolling release of new versions of the standard allowed the introduction of the functional programming paradigm, of ranges, of new primitives for parallel and asynchronous programming, of move semantics. But the biggest change for anyone who wants to learn C++ today is the simplification of memory management and the introduction of auto types. The big breakthrough offered by these changes is that a Java or C# programmer can understand modern C++ programs, something we weren’t sure about back when Java and C# started.

This means the language is much easier to learn today than in the 90s. A good example of this change is the complete irrelevance of the old exam question on the difference between an array to pointers or a pointer to arrays; naked arrays can easily be replaced with a vector<> or a list<>, while pointers are replaced with the more precise shared_pointer<> or unique_pointer<>. This in turn reduces concerns related to allocation and release of memory for the pointers, thus both cleaning up the code and reducing the potential for the inscrutable error messages so prevalent in C++ 98.

We can’t say, however, that the C++ language is as easy to learn as the other mainstream ones today. Let’s see why.

Is C++ as easy to learn as Java, C#, PHP, JavaScript, or Python? Despite all the language improvements, the answer is: most likely not. The important question is: Should C++ be as easy to learn as all these other languages?

The demise of C++ has been predicted for a very long time. Java, then C#, and nowadays Rust were in turn touted as complete replacements for our venerable subject of debate. Instead, each of them seems to carve their own niche while C++ is still leading in programs that require careful optimization or work in constrained environments. It helps that millions of lines of C++ exist today, some of them decades old. While some of them can be turned into cloud-native, serverless, or microservices architectures, there will always be problems better fit for the engineering style serviced by C++.

We conclude, therefore, that C++ has its own purpose in the world of development, and any new programming language faces a steep uphill battle to displace it. This observation comes with its consequence: specific parts of C++ will necessarily be more difficult to grasp than other languages. While Java or C# will spare you from thinking of memory allocation and what happens with the memory when you pass arguments to another method, C++ needs to take these issues head-on and give you the option to optimize your code as your context dictates.

Therefore, if you want to understand C++, you can’t escape memory management. Fortunately, it’s much less of an issue than it used to be.

Let’s analyze the differences by looking at how different languages manage memory allocation and release. Java uses a full object-oriented (OO) approach, in which every value is an object. C# designers decided to use both value types that include the typical numeric values, chars, structs, and enums, and reference types that correspond to the objects. In Python, every value is an object, and the type can be established later in the program. All these three languages feature a garbage collector that deals with memory release. The Python language uses a reference counting mechanism in addition to the garbage collector, thus allowing it to be optionally disabled.

The C++ 98 standard didn’t provide any built-in mechanism for pointer release, instead providing the full power and responsibility for memory management to the programmer. Unfortunately, this led to problems. Suppose that you initialize a pointer and allocate a large area of memory for a value. You then pass this pointer to other methods. Who is responsible for releasing the memory?

See, for example, the following simple code sample:

BigDataStructure* pData = new pData();
call1(pData);
call2(pData);
call3(pData);

Should the caller release the memory allocated in pData? Should call3 do it? What if call3 calls another function with the same pData instance? Who is responsible for releasing it? What happens if call2 fails?

The responsibility for memory release is ambiguous and, therefore, needs to be specified for every function or for every scope, to be more precise. The complexity of this problem increases with the complexity of programs and data flows. This would make most programmers using the other mainstream languages scratch their heads or completely ignore the responsibility and end up either with memory leaks or with calls to memory areas that have been already released.

Java, C#, and Python solve all these issues without asking the programmer to be careful. Two techniques are helpful: reference counting and garbage collection. Reference counting works as follows: upon every call to copy the value, the reference count is increased. When getting out of scope, the reference count is decreased. When the reference count gets to 0, release the memory. Garbage collectors work similarly, only they run periodically and check also for circular references, ensuring that even convoluted memory structures get released correctly, albeit with a delay.

Even back in the 2000s, nothing was stopping us from implementing reference counting in C++. The design pattern is known as smart pointers and allows us to think less about these issues.

In fact, C++ had from the very beginning yet another, more elegant way, to deal with this problem: pass-by-reference. There’s a good reason why pass-by-reference is the default way to pass objects around in Java, C#, and Python: it’s very natural and convenient. It allows you to create an object, allocate its memory, pass by reference, and the best part: its memory will automatically get released upon exiting the scope. Let’s look at a similar example to the one using pointers:

BigDataStructure data{};
call1(data);
call2(data);
call3(data);
...
void call1(BigDataStructure& data){
    ...
}

This time, it doesn’t really matter what happens in call1; the memory will be released correctly after exiting the scope in which data is initialized. The only limitation of reference types is that the memory allocated for the variable cannot be reallocated. Personally, I see this as a big advantage, given that modifying data can get messy very quickly; in fact, I prefer to pass every value with const& if possible. There are, however, limited applications for highly optimized polymorphic data structures that are enabled through memory reallocation.

Looking at the preceding program, if we ignore the & sign from call1 and rename the functions to fit their corresponding conventions, we could also read Java or C#. So, C++ could have been close to these languages from the beginning. Why isn’t it still similar enough?

Well, you can’t escape memory management in C++. The preceding code would not make a Java or C# programmer think of anything more; we established that C++ is different, though. The standardization committee realized that there are situations when we need to allocate memory in one function and release it in another and that it would be ideal to avoid using pointers to do that. Enter move semantics.

Note

Move semantics is a key feature introduced in C++11 to enhance performance by eliminating unnecessary copying of objects. It allows resources to be transferred from one object to another without creating a copy, which is especially beneficial for objects that manage dynamic memory, file handles, or other resources. To utilize move semantics, you need to implement a move constructor, which initializes a new object by transferring resources from a rvalue (temporary object) to the new object, and a move assignment operator, which transfers resources from a rvalue to an existing object for your class. The std::move function is a utility that casts an object to a rvalue reference, enabling move semantics. To help, the compiler creates the move constructor in certain conditions.

See in the following example how we might use move semantics to move the scope of a variable to the function process:

BigDataStructure data{};
process(data);
...
void process(BigDataStructure&& data){
}

Not much seems different, other than using two ampersand signs. The behavior is, however, very different. The scope of the data variable moves into the called function, and process, and the memory gets released upon exiting it.

Move semantics allows us to avoid copying big data values and to transfer the responsibility for releasing the memory into called functions. This is a unique mechanic between the languages we’ve discussed until now. To my best knowledge, the only other programming languages to implement these mechanics are the other contenders for systems programming: Rust and Swift.

This proves to us that, as much as C++ resembles Java or C# nowadays, it does require programmers to understand in more detail the way memory allocation and release work. We may have gotten over the exam questions that focused on minor syntax differences with big effects, but we haven’t gotten over the need to learn more than for the other languages.

Memory management, while a big part of the conversation, is not the only thing that makes things more difficult when learning C++. A few things are different and can be a bit annoying for newcomers:

• The need for #ifndef preprocessor directives or the non-standard but often supported #pragma once to ensure that files are only included once
• Separate .h files along with arbitrary rules of what goes in .h and what goes in .cpp
• The very weird way to define interfaces with virtual methodName()=0

While we can ensure we use all these contraptions with rules and guidelines automatically applied by modern IDEs, their presence begs the question: Why are they still needed?

Barring the aforementioned, it is much more difficult to get over the fact that there’s no easy way to build a program and add external references. Java, with all its faults, has a single compiler, and Maven/Gradle as standard tools for dependency management that allow the download and integration of a new library with a simple command. C#, although fraught with the same issue for a long time, has pretty much standardized the community-created NuGet command for getting external libraries. Python features the standard pip command for managing packages.

With C++, you need to work more. Unlike Java and C#, which count on a virtual machine, your C++ programs need to be compiled for every supported target, and each target matched with the right libraries. Of course, there are tools for that. The two package managers I’ve heard mentioned the most are Conan and vcpkg. For build systems, CMake seems quite popular. The trouble is that none of these tools are standard. While it’s true that neither Java’s Maven/Gradle nor C#’s NuGet have started as a standard, their integration in tools and fast adoption means that they are the de facto standard today. C++ has a little bit more to go until this part of the language matures. We’ll talk more about these issues in a separate chapter, but it’s obvious that part of the C++ confusion is also generated by this complexity in trying out simple programs.

We looked at various complications in C++ compared to other languages, and we saw that while the language has gotten easier, it’s still not as easy as Java or C#. But the core question is: Is C++ very difficult to learn? To examine this, let’s look at three methods beginners can use to learn C++.

While the C++ standard has evolved toward simplicity, many of the learning materials have stayed the same. I can imagine it’s difficult to keep up with the C++ standard, given its newfound speed of change after 2010, and a question always remains: How much code is using the latest standard? Won’t students need to learn anyway the old ways of C++ so that they can deal with decades-old code bases?

Despite this possibility, we must progress at some point, and Bjarne Stroustrup thought the same. The third edition of his book, Programming: Principles and Practice using C++ (https://www.amazon.com/Programming-Principles-Practice-Using-C-ebook/dp/B0CW1HXMH3/), published in 2024, is addressed to beginners in programming and takes them through the C++ language. The book is a very good introduction to C++, and it’s accompanied by examples and a slide deck useful for anyone who wants to teach or learn the language.

It’s interesting to note that Stroustrup does not shy away from the topic of pointers and memory management, instead discussing the minimum necessary and immediately showing the ways modern C++ avoids them.

Let’s take as an example the slides associated with Chapter 16 that focus on arrays. They start with an explanation of naked arrays, their connection with pointers, and how you can get in trouble when using pointers. Then, alternatives are introduced: vector, set, map, unordered_map, array, string, unique_ptr, shared_ptr, span, and not_null. The deck ends with an example of a palindrome implementation in multiple ways, comparing the differences in safety and brevity of the code. Therefore, the whole purpose of this chapter is to show the various issues with arrays and pointers and how STL structures help avoid these issues.

The resulting code closely resembles the Java or C# variants. However, Stroustrup points out that pointer arithmetic is still useful to implement data structures. In other words, use it sparingly and only when you really need heavy optimizations.

We conclude, therefore, that the language creator doesn’t shy away from pointers and memory management but is focused on removing a lot of the potential issues that come with it. This enables C++ programmers to care less about memory management than in the C++ 98 era, but still a little bit more than in Java or C#.

The question still stands: Could beginners learn C++ without thinking much about pointers? Another teaching method seems to prove this is possible – if we want to train library users instead of library creators.