{"id":5412,"date":"2018-03-26T18:55:38","date_gmt":"2018-03-26T18:55:38","guid":{"rendered":"https:\/\/www.modernescpp.com\/index.php\/no-new-new\/"},"modified":"2023-06-26T11:53:46","modified_gmt":"2023-06-26T11:53:46","slug":"no-new-new","status":"publish","type":"post","link":"https:\/\/www.modernescpp.com\/index.php\/no-new-new\/","title":{"rendered":"No New New: Raw Pointers Removed from C++"},"content":{"rendered":"

Two weeks ago, the ISO C++ standard meeting took place in Jacksonville.  Today I want to make a short detour and write about the revolutionary decision that was made in the Jacksonville meeting. Additionally, I refer to the post C++ Will no Longer Have Pointers<\/a> by Fluent C++. The standard committee decided that pointers will be deprecated in C++20 and will, with a very high probability, be removed in C++23.<\/p>\n

<\/p>\n

Honestly, what seems like a revolution is only the last step in a long evolution. First, let me explain the big picture.<\/p>\n

 \"memory\"<\/p>\n

The evolution of pointers in C++<\/h3>\n

Pointers have been part of C++ since the first beginning. We got them from C. From the first beginning, there was always the tendency in C++ to make the handling with pointers more type-safe without paying the extra cost.<\/p>\n

With C++98 we got std::auto_ptr <\/span>to express exclusive ownership. But std::auto_ptr <\/span>had a big issue. When<\/span> you copy a std::auto_ptr <\/span>t<\/span><\/span>he resource will be moved. What looks like a copy operation was a move operation. The graphic shows the surprising behavior of a std::auto_ptr<\/span>.
<\/span><\/span><\/p>\n

\"autoPtrCopy\"<\/p>\n

This was extremely bad and the reason for many serious bugs; therefore, we got std::unique_ptr<\/span> with C++11, and std::auto_ptr<\/span> was deprecated in C++11 and finally removed in C++17. Additionally, we got std::shared_ptr<\/span> and std::weak_ptr<\/span> in C++11 for handling shared ownership. You can not copy but move a std::unique_ptr<\/span>, and if you copy or assign a std::shared_ptr<\/span>, the internal reference counter will be increased. Have a look here:<\/p>\n

\"uniquePtrCopy\"<\/p>\n

\"sharedPtr\"<\/p>\n

Since C++11 C++ has a multithreading library, this makes the handling with std::shared_ptr<\/span> quite challenging because a std::shared_ptr<\/span> is per definition shared but not thread-safe. Only the control block is thread-safe but not the access to its resource. That means modifying the reference counter is an atomic operation and you have the guarantee that the resource will be deleted exactly once. This is the reason we will get C++20 atomic smart pointers: std::atomic_shared_ptr<\/span> and std::atmic_weak_ptr<\/span>. Read the details in the proposal: Atomic Smart Pointers<\/a>.<\/p>\n

Now to the more exciting part of C++20 and C++23. Pointers will be deprecated in C++20 and removed in C++23. Or to say it with three words: N<\/strong>o N<\/strong>ew N<\/strong>ew (NNN).<\/p>\n

std::unique_ptr to our rescue<\/h3>\n

But hold, we have a dogma in C++: Don’t pay for anything you don’t need. How can we program without a pointer? Just use an std::unique_ptr.<\/span> A std::unique_ptr<\/span> is by design as fast and as slim as a raw pointer but has a great benefit: it automatically manages its resource.<\/p>\n

Only to remind you. Here is a simple performance test.<\/p>\n

\n
\/\/ all.cpp<\/span>\r\n\r\n#include <chrono><\/span>\r\n#include <iostream><\/span>\r\n\r\nstatic<\/span> const<\/span> long<\/span> long<\/span> numInt=<\/span> 100000000<\/span>;\r\n\r\nint<\/span> main<\/span>(){\r\n\r\n  auto<\/span> start =<\/span> std::<\/span>chrono::<\/span>system_clock::<\/span>now();\r\n\r\n  for<\/span> ( long<\/span> long<\/span> i=<\/span>0<\/span> ; i <<\/span> numInt; ++<\/span>i){\r\n    int<\/span>*<\/span> tmp(new<\/span> int<\/span>(i));\r\n    delete<\/span> tmp;\r\n    \/\/ std::shared_ptr<int> tmp(new int(i));<\/span>\r\n    \/\/ std::shared_ptr<int> tmp(std::make_shared<int>(i));<\/span>\r\n    \/\/ std::unique_ptr<int> tmp(new int(i));<\/span>\r\n    \/\/ std::unique_ptr<int> tmp(std::make_unique<int>(i));<\/span>\r\n  }\r\n\r\n  std::<\/span>chrono::<\/span>duration<<\/span>double<\/span>><\/span> dur=<\/span> std::<\/span>chrono::<\/span>system_clock::<\/span>now() -<\/span> start;\r\n  std::<\/span>cout <<<\/span> \"time native: \"<\/span> <<<\/span> dur.count() <<<\/span> \" seconds\"<\/span> <<<\/span> std::<\/span>endl;\r\n\r\n}\r\n<\/pre>\n<\/div>\n
 <\/p>\n
The program allocates and deletes 100.000.000 ints.  I use a raw pointer, std::shared_ptr,<\/span> and std::unique_ptr<\/span> in two variations. I executed the program with and without maximum optimization on Linux and Windows. Here are the numbers.<\/p>\n
 \"comparisonEng\"<\/p>\n
The numbers show it black on blue. The two variations of std::unique_ptr<\/span> are as fast as the raw pointers on Linux and Windows. For the details of the numbers, read my previous post: Memory and Performance Overhead of Smart Pointers<\/a>.<\/p>\n
Ownership semantic<\/h3>\n
We use pointers, particularly raw pointers, far too often. The question if you should use a pointer boils down to one question: Who is the owner? Luckily, we can directly express our intention about ownership in code.<\/p>\n