Raw Pointers Are Gone!

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.

Previous Post
Next Post

13 Comments



    1. I imagine they’d use compiler intrinsic pointers. But luckily pointers aren’t going anywhere. See the update too the post ๐Ÿ˜‰

      Reply

  1. I love the tradicional pointers (a decent real time/critical sysrem is based on it), I don’t tink it can be turn off. The low level (near to HW), microcontrollers, IoT, Robotics, etc must to request raw pointer for ever :=)

    Reply

    1. I agree. Many times the problem is that embedded / low level c++ programmers are simply not represented in the committee, or in blogs that write about its meetings ๐Ÿ˜‰

      In any case, i don’t think it’s practical. One of the guidelines for deprecating a feature is that it breaks as little code as possible, and clearly that cannot be said for raw pointers.

      Reply

      1. There are efforts to fix the underrepresentation of embedded development in the committee. SG14 is also dedicated to those areas. There are, for example, efforts to have containers and other classes for those special needs in the standard library. And, of course, they will be implemented using pointers. Pointers are going nowhere – see the update in the post ๐Ÿ˜‰

        Reply

    2. Of course pointers are needed. They are an essential part of the language and will be going nowhere. See the update to the post ๐Ÿ˜‰

      Reply

  2. Was this an April 1st post? ๐Ÿ™‚

    Reply

    1. Nah, they’ll stick around. They have endured auto type deduction, range based for loops and lots if other changes. They’ll go through this as well!

      Reply

      1. I have to disagree. All the features you described are just that – features, additions to the language.
        This is very different than removing a very basic and powerful part of the core language.

        Reply

Leave a Reply

Your email address will not be published. Required fields are marked *