You are already aware of the dangers of using pointers for dynamically allocated memory. Fortunately, since the c++11 standard, programmers have the option of using Smart Pointer classes to facilitate memory management with pointers. This allows C++ to have a limited-functionality garbage collection that works transparent to the programmer with minimal overhead compared to a standard built-in pointer type.
Smart Pointers come in several flavors: unique_ptr
, shared_ptr
, weak_ptr
, and auto_ptr
. These are defined in the library and will be discussed next.
src/main1.cpp
contains an example of the unique_ptr use.
std::unique_ptr<T>
is a templated class that does not allow copying pointers directly using direct assignment (e.g., p1 = p2
). std::unique_ptr<T>
requires transfer of ownership to another std::unique_ptr<T>
instance.
When the pointer has completed it's useful life, the memory contents are freed. Further attempts to access this memory will result in a segmentation fault.
Since smart pointers are part of the c++11 stardard, you may need to use the following CMake flags when creating your build environment.
mkdir build
cd build
cmake -DCMAKE_CXX_FLAGS=-std=c++11 -DCMAKE_CXX_COMPILER=g++ ..
make ex11p1
Note that the program does not output anything to stdout. You can look at the code comments to understand how to use the unique_ptr<T>
.
src/main2.cpp
contains an example of the shared_ptr use.
Unlike unique pointers, shared pointers do allow multiple pointers to reference the same memory space. This can be useful when passing pointers into functions or other objects.
std::shared_ptr<T>
is a safer means of using multiple pointers to access the same memory. This object keeps a running count of how many times it has been used. When count == 0, no known uses exist and memory is freed.
Like the unique_ptr, once the shared_ptr has been reset it will produce a segmentation fault.
src/main3.cpp
contains an example of the weak_ptr use.
A std::weak_ptr<T>
instance can behave like a std::shared_ptr<T>
instance, but it does not contribute to the "shared ownership" of the resource. In other words, it will not add to the reference count held by the shared_ptr instance.
The problem for the weak_ptr is to handle the appropriate case where the object it points to no longer exists. std::weak_ptr<T>
is typically used alongside std::shared_ptr<T>
to augment rather than replace a shared_ptr functionality.
std::auto_ptr<T>
was the first attempt in the C++98 standard to create what is currently std::unique_ptr<T>
. Unless the programmer requires code to be backward compatible to a C++98 compiler, you should always use unique_ptr
instead.