There’s some great news coming from the C++ standards committee: Raw pointers are gone – or rather will be in C++20.

Update 2018-04-02: This post was, of course, an April fool’s joke. Together with four other bloggers we decided to orchestrate a bunch of blog posts about this topic. For credibility, we referred to each other’s posts, creating a circular reference:

I link to Bartolomiej Filipek
who links to Rainer Grimm
who links to Jonathan Boccara
who links to Simon Brand
who links back here.

Gone, finally

Two weeks ago, the ISO C++ standards meeting in Jacksonville has ended. In that meeting, the standards committee has decided on things that will go into C++20 and C++23, including the removal of raw, C-style pointers. They won’t be completely gone in C++20 yet – that would be too much of a breaking change. In the spirit of other removals from the last standards (e.g. auto_ptr and dynamic exception specifications), raw pointers will be deprecated in C++20 and then completely removed in either C++23 or C++26.

Why this is a good thing

Raw pointers have been a pain in the backside for most students learning C++ in the last decades. They had a multi-purpose role as raw memory iterators, nullable, changeable nullable references and devices to manage memory that no-one really owns. This lead to a host of bugs and vulnerabilities and headaches and decades of human life spent debugging, and the loss of joy in programming completely.

Whenever I tell a non-C++ programmer that I mostly work with C++, the usual first reaction is “Oh. Pointer arithmetics”. Now, I finally can look forward to answering “Nope, that’s ancient history”.

But how…?

The removal of raw pointers obviously poses some problems that are not all easy to solve. What about the STL containers and smart pointers that are implemented using raw pointers? Well, one of the perks of being a library implementor is to have access to compiler intrinsics. Since compilers will have to handle addresses internally regardless of what we can use in the language, there probably will be some kind of intrinsic pointers. Those then could be used by library implementers.

What about pointers to iterate memory? For every container that has contiguous storage, we already have iterators. We also have std::raw_storage_iterator to deal with uninitialized memory. Even today, raw pointers as iterators only make sense for raw C-arrays. As far as I can see, those will probably deprecated and removed as well. After all, we have std::array which is much more convenient.

The last thing that remains is the “nullable reference” semantic that pointers provide. For this, optional references could be a convenient solution. They might be a bit more verbose, but in my opinion, that is just fine. Explicitly using std::optional<T&> makes the semantics much clearer than conjuring the devils of C where we do not really know whether a T* does own the object it points to or whether it really is just a reference.

Conclusion

We live in exciting days. At last the committee hears the demands of C++ users and takes bold steps to make the language simpler and more usable. With pointers, lots of the pitfalls of old are going to vanish.