wiki.accu.org

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Back to [[conference:committee:2015-proposals]]\\
\\
**Title**: How many Smart Pointers does the C++ standard need?\\
**Proposer**: [[2015:Peter Sommerlad]]\\
**Type**: Tutorial\\
**Duration**: 90 mins\\
**Description**: \\
Plain pointers in C++ where inherited from C and are still in heavy use. However, operator overloading of C++ allows to create "smart" pointers that can be used like plain pointers but provide additional features, such as reference counting and automatic memory management.\\
\\
The main problem with a plain pointer is that it can mean so many things. It can point to an object anywhere in memory. This can be allocated storage that the pointer user is responsible for, or it can be just an object on the stack, which's address is passed to a function down the call hierarchy. A plain C-style array when passed to a function degenerates to a pointer to the first element, losing the dimension. That also implies that any pointer can point not only to a single element, but also to the first element of an array of elements of unknown dimension. In the case of char* additional convention of a NUL-terminated character sequence representing C strings comes into play. All of that, plus Toni Hoare's multi-billion mistake of allowing pointers to be NULL (or nullptr in modern C++), so a pointer can either point to something or be empty. To make things worse, pointers can be uninitialized or dangling leading to invalid memory accesses that might crash the program immediately, or introduce subtle hard to find bugs, that can lead to miscalculations, security errors, or crashes that come much later and are very hard to debug, because the memory corruption was happening far from the crash location. This all let's the author conclude: plain pointers are very BAD, because all of the above semantics are given through a single type constructor: T*.\\
\\
C++98's tried to solve the memory management problem with std::auto_ptr, which turned out to be a disaster in waiting, due to its "interesting" copy-semantics.\\
\\
With C++11's introduction of std::unique_ptr and std::shared_ptr, the first enabled by move semantics and the second made (partially) safe reference counted pointer due to atomics, the standard provided useful smart pointers for memory management.\\
\\
However, during the course of the years and also within the Boost library, several other smart pointer types where introduced and proposed for standardization (also by the author), but up to now, none took the hurdle of the C++ standardization committee. This talk will show some of them and will also try to map out the dimensions of what a plain pointer can mean and what (future) standard classes are available as an alternative to a plain pointer in that situation. Hopefully, the map will help guide future standardization of other useful smart pointers, or give guidelines to users of pointers on how to refactor their code to give more guidance to the the code users on what a pointer actually means.\\
\\
The talk might show also some tooling supporting the refactoring away from C-style pointers and arrays towards using std::string and std::array instead.\\
\\
\\
\\