The inventor of null references has called them his billion dollar mistake. We’ve all felt that pain so many times. After a while it can seem like null references are inevitable. They’re just a built-in sharp edge we have to carefully avoid cutting ourselves on. But is this true? Is there some way we can avoid the possibility of a null reference in the first place? Today we’ll go searching for such a mythical type.
Today we conclude the series by reflecting on how C++ and C#, as well as their standard libraries, compare. We’ll also think a little about how their differences change the way we write code.
As a very large language used for a very wide range of purposes over many decades, C++ can be written in a lot of different ways. Today we’ll look at some of the norms for “modern” C++ to get a sense of how code is normally written.
Despite the C++ Standard Library having 13 articles worth of content, there’s still quite a bit that it doesn’t contain compared to what’s available in C#’s .NET libraries. Today we’ll look at some of those gaps and see how to fill them.
We’ve seen a bit of I/O in the C Standard Library already, but this isn’t C++’s main way to perform I/O. Today we’ll look at the “streams” API that’s designed around C++’s support for strong types and overloaded operators rather than facilities like “format strings.” We’ll also see how to write the canonical “Hello, world!” program in C++ and how to finally implement
Generic algorithms have been available in C++ for decades, but the last two versions of the language have really ramped up the functionality. C++17 added support for parallel execution of generic algorithms to easily take advantage of multi-core CPUs. Then C++20 added support for ranges, a composable version of generic algorithms that’s even closer to LINQ in C#. Today we’ll explore both of these!
The C++ Standard Library’s algorithms are culmination of a lot of C++ language and library features. They’re like a much more featureful, much faster version of LINQ in C#. This powerful combination makes most “raw” loops unnecessary as they can be replaced by named function calls that are well-tested and often compile to the same machine code as a “raw” loop. Read on to learn about them!
We’ve covered all the individual container types, so let’s take a step back and look at the containers library as a whole. A lot of features, like support for range-based
for loops and allocator customization, are supported in all container types. Today we’ll take a look at the commonalities between the containers and see what ties them together into a cohesive library.