Hubbry Logo
Smart pointerSmart pointerMain
Open search
Smart pointer
Community hub
Smart pointer
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Smart pointer
Smart pointer
Smart pointer
View on Wikipedia
from Wikipedia

In computer science, a smart pointer is an abstract data type that simulates a pointer while providing added features, such as automatic memory management or bounds checking. Such features are intended to reduce bugs caused by the misuse of pointers, while retaining efficiency. Smart pointers typically keep track of the memory they point to, and may also be used to manage other resources, such as network connections and file handles. Smart pointers were first popularized in the programming language C++ during the first half of the 1990s as rebuttal to criticisms of C++'s lack of automatic garbage collection.[1][2] Rust, which avoids raw pointers and uses ownership to dictate lifetimes, also has smart pointers.

Pointer misuse can be a major source of bugs. Smart pointers prevent most situations of memory leaks by making the memory deallocation automatic. More generally, they make object destruction automatic: an object controlled by a smart pointer is automatically destroyed (finalized and then deallocated) when the last (or only) owner of an object is destroyed, for example because the owner is a local variable, and execution leaves the variable's scope. Smart pointers also eliminate dangling pointers by postponing destruction until an object is no longer in use.

If a language supports automatic garbage collection (for example, Java or C#), then smart pointers are unneeded for reclaiming and safety aspects of memory management, yet are useful for other purposes, such as cache data structure residence management and resource management of objects such as file handles or network sockets. Java, although not having a pointer API, has similar concepts for dealing with references.

Several types of smart pointers exist. Some work with reference counting, others by assigning ownership of an object to one pointer.

History

[edit]

Even though C++ popularized the concept of smart pointers, especially the reference-counted variety,[3] the immediate predecessor of one of the languages that inspired C++'s design had reference-counted references built into the language. C++ was inspired in part by Simula67.[4] Simula67's ancestor was Simula I. Insofar as Simula I's element is analogous to C++'s pointer without null, and insofar as Simula I's process with a dummy-statement as its activity body is analogous to C++'s struct (which itself is analogous to C. A. R. Hoare's record in then-contemporary 1960s work), Simula I had reference counted elements (i.e., pointer-expressions that house indirection) to processes (i.e., records) no later than September 1965, as shown in the quoted paragraphs below.[5]

Processes can be referenced individually. Physically, a process reference is a pointer to an area of memory containing the data local to the process and some additional information defining its current state of execution. However, for reasons stated in the Section 2.2 process references are always indirect, through items called elements. Formally a reference to a process is the value of an expression of type element.
…
element values can be stored and retrieved by assignments and references to element variables and by other means.
The language contains a mechanism for making the attributes of a process accessible from the outside, i.e., from within other processes. This is called remote access- ing. A process is thus a referenceable data structure.

It is worth noticing the similarity between a process whose activity body is a dummy statement, and the record concept recently proposed by C. A. R. Hoare and N. Wirth

Because C++ borrowed Simula's approach to memory allocation—the new keyword when allocating a process/record to obtain a fresh element to that process/record—it is not surprising that C++ eventually resurrected Simula's reference-counted smart-pointer mechanism within element as well.

Features

[edit]

In C++, a smart pointer is implemented as a template class that mimics, by means of operator overloading, the behaviors of a traditional (raw) pointer, (e.g. dereferencing, assignment) while providing additional memory management features.

Smart pointers can facilitate intentional programming by expressing, in the type, how the memory of the referent of the pointer will be managed. For example, if a C++ function returns a pointer, there is no way to know whether the caller should delete the memory of the referent when the caller is finished with the information. 

SomeType* ambiguousFunction();  // What should be done with the result?

Traditionally, naming conventions have been used to resolve the ambiguity,[6] which is an error-prone, labor-intensive approach. C++11 introduced a way to ensure correct memory management in this case by declaring the function to return a std::unique_ptr, 

unique_ptr<SomeType> obviousFunction();

The declaration of the function return type as a unique_ptr makes explicit the fact that the caller takes ownership of the result, and the C++ runtime ensures that the memory will be reclaimed automatically. Before C++11, unique_ptr can be replaced with auto_ptr, which is now deprecated.

Creating new objects

[edit]

To ease the allocation of a std::shared_ptr<SomeType>, C++11 introduced: 

shared_ptr<SomeType> s = std::make_shared<SomeType>(constructor, parameters, here);

and similarly std::unique_ptr<SomeType>, since C++14 one can use: 

unique_ptr<SomeType> u = std::make_unique<SomeType>(constructor, parameters, here);

It is preferred, in almost all circumstances, to use these facilities over the new keyword.[7]

Unique pointers

[edit]

C++11 introduces std::unique_ptr, defined in the header <memory>.[8]

A unique_ptr is a container for a raw pointer, which the unique_ptr is said to own. A unique_ptr explicitly prevents copying of its contained pointer (as would happen with normal assignment), but the std::move function can be used to transfer ownership of the contained pointer to another unique_ptr. A unique_ptr cannot be copied because its copy constructor and assignment operators are explicitly deleted. 

using std::unique_ptr;

unique_ptr<int> p1(new int(5));
unique_ptr<int> p2 = p1;  // Compile error.
unique_ptr<int> p3 = std::move(p1);  // Transfers ownership. p3 now owns the memory and p1 is set to nullptr.

p3.reset();  // Deletes the memory.
p1.reset();  // Does nothing.

std::auto_ptr is deprecated under C++11 and completely removed from C++17. The copy constructor and assignment operators of auto_ptr do not actually copy the stored pointer. Instead, they transfer it, leaving the prior auto_ptr object empty. This was one way to implement strict ownership, so that only one auto_ptr object can own the pointer at any given time. This means that auto_ptr should not be used where copy semantics are needed.[9][citation needed] Since auto_ptr already existed with its copy semantics, it could not be upgraded to be a move-only pointer without breaking backward compatibility with existing code.

The Rust equivalent of unique pointers is std::boxed::Box, which has unique ownership of a heap allocated object.[10]. In previous versions of Rust, there was also a std::ptr::Unique that wrapped around raw non-null *mut T.[11]

Shared pointers and weak pointers

[edit]
Main article: Weak reference

C++11 introduces std::shared_ptr and std::weak_ptr, defined in the header <memory>.[8] C++11 also introduces std::make_shared (std::make_unique was introduced in C++14) to safely allocate dynamic memory in the RAII paradigm.[12]

A shared_ptr is a container for a raw pointer. It maintains reference counting ownership of its contained pointer in cooperation with all copies of the shared_ptr. An object referenced by the contained raw pointer will be destroyed when and only when all copies of the shared_ptr have been destroyed. 

using std::shared_ptr;

shared_ptr<int> p0(new int(5)); // Valid, allocates 1 integer and initialize it with value 5.
shared_ptr<int[]> p1(new int[5]); // Valid, allocates 5 integers.
shared_ptr<int[]> p2 = p1; // Both now own the memory.

p1.reset(); // Memory still exists, due to p2.
p2.reset(); // Frees the memory, since no one else owns the memory.

A weak_ptr is a container for a raw pointer. It is created as a copy of a shared_ptr. The existence or destruction of weak_ptr copies of a shared_ptr have no effect on the shared_ptr or its other copies. After all copies of a shared_ptr have been destroyed, all weak_ptr copies become empty. 

using std::shared_ptr;
using std::weak_ptr;

shared_ptr<int> p1 = std::make_shared<int>(5);
weak_ptr<int> wp1{p1};  // p1 owns the memory.

{
    shared_ptr<int> p2 = wp1.lock();  // Now p1 and p2 own the memory.
    // p2 is initialized from a weak pointer, so you have to check if the
    // memory still exists!
    if (p2) {
        useSomePointer(p2);
    }
}
// p2 is destroyed. Memory is owned by p1.

p1.reset();  // Free the memory.

shared_ptr<int> p3 = wp1.lock(); 
// Memory is gone, so we get an empty shared_ptr.
if (p3) {  // code will not execute
    useLivePointer(p3);
}

Because the implementation of shared_ptr uses reference counting, circular references are potentially a problem. A circular shared_ptr chain can be broken by changing the code so that one of the references is a weak_ptr.

Multiple threads can safely simultaneously access different shared_ptr and weak_ptr objects that point to the same object.[13]

The referenced object must be protected separately to ensure thread safety.

shared_ptr and weak_ptr are based on versions used by the Boost libraries.[citation needed] C++ Technical Report 1 (TR1) first introduced them to the standard, as general utilities, but C++11 adds more functions, in line with the Boost version.

In Java, every object is effectively a shared reference, and the Java Virtual Machine (JVM) tracks object reachability. Rust has two kinds of shared pointers, std::rc::Rc (reference-counted, single-threaded) and std::sync::Arc (atomically reference-counted, thread-safe).

Java has an equivalent concept to weak pointers, java.lang.ref.WeakReference (implementing a weak reference), which does not increase the reference count of an object, and can check that an object still lives using WeakReference::get. Java similarly has the java.lang.ref.PhantomReference (implementing a phantom reference), used with a java.lang.ref.ReferenceQueue, for performing cleanup actions after an object is garbage collected, but prior to finalisation. Unlike WeakReference), PhantomReference cannot actually access the object. java.lang.ref.SoftReference, on the other hand, are cleared according to the discretion of the garbage collector. Rust has a std::rc::Weak for a weak, non-owning reference which is created from an Rc or Arc by using downgrade().[14]

Hazard pointers

[edit]
Main article: Hazard pointer

Starting in C++26, there is a new pointer defined in <hazard_pointer>, the hazard pointer (std::hazard_pointer). It is a single-writer multi-reader pointer that can be owned by at most one thread at any point in time.

The hazard pointer had existed already previously in some third-party libraries.[15]

Other types of smart pointers

[edit]

There are other types of smart pointers (which are not in the C++ standard) implemented on popular C++ libraries or custom STL, some examples include the intrusive pointer.[16][17]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Smart pointer

View on Grokipedia
from Grokipedia
A smart pointer is a programming construct, typically implemented as a class or template in languages like C++, that wraps a raw pointer to an object and provides automatic , ensuring the pointed-to resource is deallocated when the smart pointer is destroyed or reset, thereby preventing memory leaks and dangling pointers. In the , smart pointers are defined in the <memory> header and were formally introduced in C++11 to promote (RAII) principles, allowing exception-safe handling of dynamically allocated objects without manual intervention via delete. The primary types include std::unique_ptr, which enforces exclusive ownership through move semantics and automatic deletion upon scope exit; std::shared_ptr, which enables shared ownership via to track the number of s and deallocate only when the count reaches zero; and std::weak_ptr, a non-owning to a shared_ptr-managed object that helps break potential circular references without affecting the ownership count. These mechanisms replace the deprecated std::auto_ptr from pre-C++11 standards, offering safer and more efficient alternatives for modern . Smart pointers enhance code reliability by integrating with C++'s scoping rules and destructors, eliminating the need for explicit cleanup in most cases, while maintaining performance comparable to raw pointers through minimal overhead—such as a single pointer's size for unique_ptr or two for shared_ptr due to its control block. They are particularly valuable in multi-threaded environments and complex applications where is error-prone, though they require careful use to avoid issues like unnecessary overhead from shared ownership or exceptions during .

Introduction

Definition and Purpose

Smart pointers in C++ are template classes designed to encapsulate raw pointers and automate the management of dynamically allocated objects, ensuring automatic deallocation through their destructors when the smart pointer instances go out of scope. This approach adheres to the idiom, where resource acquisition occurs during object construction and release is guaranteed during destruction, even in the presence of exceptions. By wrapping a raw pointer, a smart pointer provides a safer interface for accessing the underlying object while handling its lifetime transparently. The primary purposes of smart pointers include eliminating the need for explicit manual calls to delete, thereby reducing the risk of forgetting deallocation in complex code paths. They also enforce clear semantics, either exclusive—where a single smart pointer owns the resource and transfers ownership upon reassignment—or shared, where multiple smart pointers can co-own the resource through mechanisms like , with deallocation occurring only when the last owner is destroyed. This integration with ensures exception-safe , as the stack unwinding process automatically invokes destructors without requiring additional try-catch blocks for cleanup. Key benefits of smart pointers encompass a significant reduction in memory leaks, which arise from un-deleted objects in raw pointer usage, and prevention of such as double deletions when multiple pointers inadvertently manage the same resource. Compared to raw pointers, which demand meticulous manual tracking and can lead to errors in large-scale applications, smart pointers simplify code maintenance and promote more reliable practices. Overall, they shift the burden of lifetime from the programmer to the language's automatic mechanisms, fostering safer and more concise expressions of intent.

Comparison to Raw Pointers

Raw pointers in C++, denoted as T*, require explicit manual allocation using new and deallocation using delete, which makes them susceptible to memory leaks if the delete call is omitted or if an exception occurs before deallocation, preventing proper cleanup. Additionally, raw pointers permit multiple pointers to reference the same object without enforcing rules, potentially leading to double deletion if multiple delete calls are made on the same memory, resulting in such as crashes or corruption. Smart pointers address these issues by automating resource management through the RAII (Resource Acquisition Is Initialization) principle, eliminating the need for manual deallocation and ensuring cleanup occurs deterministically when the pointer goes out of scope. They provide compile-time enforcement of ownership semantics, such as prohibiting copying for unique ownership models to prevent unintended sharing, and offer exception safety by guaranteeing resource release even if an exception propagates during stack unwinding. To illustrate, consider a scenario with raw pointers where an exception causes a memory leak:

cpp

#include <iostream> #include <stdexcept> struct Resource { Resource() { std::cout << "Resource acquired\n"; } ~Resource() { std::cout << "Resource released\n"; } }; void processRaw() { Resource* res = new Resource(); if (true) { // Simulate condition throw std::runtime_error("Exception thrown"); } delete res; // Never reached due to exception } int main() { try { processRaw(); } catch (...) { // Leak: res not deleted } return 0; }

#include <iostream> #include <stdexcept> struct Resource { Resource() { std::cout << "Resource acquired\n"; } ~Resource() { std::cout << "Resource released\n"; } }; void processRaw() { Resource* res = new Resource(); if (true) { // Simulate condition throw std::runtime_error("Exception thrown"); } delete res; // Never reached due to exception } int main() { try { processRaw(); } catch (...) { // Leak: res not deleted } return 0; }

In this example, the Resource is allocated but not deallocated because the exception bypasses the delete statement, leading to a memory leak. In contrast, using a smart pointer like std::unique_ptr ensures automatic cleanup:

cpp

#include <iostream> #include <memory> #include <stdexcept> struct [Resource](/page/Resource) { Resource() { std::cout << "Resource acquired\n"; } ~Resource() { std::cout << "Resource released\n"; } }; void processSmart() { auto res = std::make_unique<Resource>(); if (true) { throw std::runtime_error("Exception thrown"); } // No manual delete needed } int main() { try { processSmart(); } catch (...) { // No leak: destructor called on scope exit } return 0; }

#include <iostream> #include <memory> #include <stdexcept> struct [Resource](/page/Resource) { Resource() { std::cout << "Resource acquired\n"; } ~Resource() { std::cout << "Resource released\n"; } }; void processSmart() { auto res = std::make_unique<Resource>(); if (true) { throw std::runtime_error("Exception thrown"); } // No manual delete needed } int main() { try { processSmart(); } catch (...) { // No leak: destructor called on scope exit } return 0; }

Here, the Resource destructor is invoked automatically upon exception, preventing the leak. For shared ownership, std::shared_ptr uses to track owners and deletes the object only when the count reaches zero, avoiding double deletion risks inherent in raw pointers. While smart pointers introduce minor runtime overhead—such as in std::shared_ptr, which involves atomic operations for —they significantly reduce common errors like use-after-free, dangling pointers, and leaks, promoting safer code with negligible performance impact in most cases, as std::unique_ptr matches the size and speed of raw pointers.

Historical Development

Early Approaches Before C++11

Before the introduction of standardized smart pointers in , C++ developers addressed challenges through the (RAII) idiom, often implementing custom or library-based wrappers around raw pointers to ensure automatic deallocation. These early efforts aimed to mitigate common issues like memory leaks and dangling pointers in pre-C++98 code, where manual calls to delete were prone to errors, especially in exception-handling scenarios. The C++98 standard introduced std::auto_ptr as the first official smart pointer, designed to provide exclusive of dynamically allocated objects by automatically invoking delete in its destructor. Developed through proposals dating back to 1997, auto_ptr relied on copy-and-swap semantics to transfer during assignment or copying, intending to enforce single . However, this design led to subtle bugs, as copying invalidated the original pointer without clear indication, making it unsafe for use in (STL) containers that expect stable value semantics during operations like resizing. To overcome auto_ptr's limitations and support more flexible ownership models, the Boost Smart Pointer library emerged in the late as a widely adopted non-standard solution. Originating from community efforts around 1999, it prototyped shared_ptr, which implemented shared ownership via atomic , allowing multiple pointers to manage the same object until the last one was destroyed. This library also included scoped_ptr for strict exclusive ownership within a single scope—non-copyable to avoid unintended transfers—and intrusive_ptr for legacy objects with embedded reference counts, reducing overhead in existing codebases. Boost's implementations were battle-tested in production and directly shaped later standards. Despite their utility, these pre-C++11 approaches had significant drawbacks. Boost components, while influential, were not part of the , resulting in varying implementations across compilers and potential portability issues. auto_ptr's unexpected transfer semantics often caused confusion and errors, as evidenced by its in C++11 in favor of safer alternatives. Custom RAII wrappers, commonly hand-rolled for specific resources like mutex guards or file handles, further compounded inconsistencies, lacking the robustness and interoperability of unified designs.

Standardization in C++11 and Beyond

In C++11, smart pointers were formally integrated into the through the adoption of Technical Report 1 (TR1) components and new additions in the <memory> header. The std::shared_ptr and std::weak_ptr classes, originally specified in ISO/IEC TR 19768:2007, were elevated to full standard status with refinements for move semantics and aliasing constructors to enhance efficiency and usability. Simultaneously, std::unique_ptr was introduced as a modern replacement for std::auto_ptr, providing exclusive ownership without the aliasing issues that plagued its predecessor; this was driven by proposals like N2853, which emphasized move-only semantics to align with C++11's rvalue reference features. The std::auto_ptr was deprecated in the same standard due to its incompatibility with containers and unexpected transfer-of-ownership behavior during copying. Key milestones in the standardization process included the 2009 proposal N3050, which formalized aspects of move constructors and noexcept specifications to ensure safe integration of unique_ptr with exception-safe code. in shared_ptr was also refined to support atomic operations, enabling thread-safe use without external locking in many scenarios. These changes collectively addressed long-standing concerns with raw pointer management, promoting RAII principles at the language level. Subsequent standards built on this foundation with targeted improvements. C++14 introduced std::make_unique via proposal N3656, a factory function that allocates and constructs objects in a single expression, reducing exception safety risks compared to direct use of new with unique_ptr. In C++17, std::auto_ptr was fully removed to streamline the library and eliminate deprecated code paths. C++23 added constexpr support for unique_ptr (via P2273R3), allowing compile-time resource management without major new pointer types. These evolutions have influenced resource management in other languages, such as Rust's Box<T> for unique ownership, though C++ remains centered on its move-enabled smart pointers.

Core Concepts

Automatic Resource Management

(RAII) is a C++ idiom that ties the lifecycle of a resource to the lifetime of an object, ensuring that resources are acquired in the constructor and released in the destructor. This approach leverages the deterministic destruction of stack-allocated objects, which occurs automatically upon scope exit or during exception stack unwinding, thereby preventing resource leaks without explicit cleanup code. In the context of smart pointers, RAII is applied to manage dynamic memory by having the smart pointer's constructor acquire the resource—typically by wrapping a raw pointer obtained from new—and its destructor invoke delete (or a custom deleter) to release it. This eliminates the need for manual memory deallocation or try-finally blocks, as the destructor's invocation is guaranteed even if an exception is thrown, ensuring exception safety. For instance, std::unique_ptr from C++11 uses this mechanism to automatically deallocate its managed object upon destruction or reassignment. To illustrate, consider the following demonstrating how RAII prevents a during an exception: Without RAII (risk of leak):

void process() { int* ptr = new int(42); // Acquire resource if (some_condition) { throw std::runtime_error("Error occurred"); // Exception thrown; delete ptr never called } delete ptr; // Release resource }

void process() { int* ptr = new int(42); // Acquire resource if (some_condition) { throw std::runtime_error("Error occurred"); // Exception thrown; delete ptr never called } delete ptr; // Release resource }

With RAII (smart pointer ensures release):

void process() { std::unique_ptr<int> ptr(new int(42)); // Acquire and manage resource if (some_condition) { throw std::runtime_error("Error occurred"); // Exception thrown; destructor auto-calls delete } // No explicit release needed; ptr's destructor handles it }

void process() { std::unique_ptr<int> ptr(new int(42)); // Acquire and manage resource if (some_condition) { throw std::runtime_error("Error occurred"); // Exception thrown; destructor auto-calls delete } // No explicit release needed; ptr's destructor handles it }

This RAII-based approach in smart pointers focuses primarily on but extends the idiom's principles to other s like file handles or mutex locks in broader C++ usage. By binding cleanup to object destruction, it promotes robust, leak-free code in exception-prone environments.

Ownership Semantics

Smart pointers in C++ enforce distinct models to manage resource lifetimes safely and prevent common errors associated with raw pointers, such as dangling references and double deletions. These models include exclusive , shared , and weak references, each designed to clarify responsibility for an object's destruction while integrating with the language's (RAII) idiom. By leveraging compile-time checks and runtime mechanisms, smart pointers eliminate the ambiguity of that raw pointers permit, where multiple pointers can alias the same object without defined deletion rules. Exclusive , as implemented in types like std::unique_ptr, assigns sole responsibility for an object's deletion to a single smart pointer instance, prohibiting sharing to avoid issues. The owner manages the resource's lifetime exclusively, and transfer of ownership occurs only through move semantics, which relocates control without copying the underlying object. Copy operations are deliberately disabled at via deleted copy constructors and assignment operators, ensuring that no two pointers can claim ownership simultaneously and preventing the risks of raw pointer , where unintended multiple deletions or leaks could arise. For instance, moving a unique_ptr resets the source to null, clearly delineating the transfer:

std::unique_ptr<int> ptr1 = std::make_unique<int>(42); std::unique_ptr<int> ptr2 = std::move(ptr1); // Ownership transfers; ptr1 is now null

std::unique_ptr<int> ptr1 = std::make_unique<int>(42); std::unique_ptr<int> ptr2 = std::move(ptr1); // Ownership transfers; ptr1 is now null

This model guarantees that the is deleted exactly once, when the owning pointer goes out of scope or is explicitly reset. Shared ownership allows multiple smart pointers, such as std::shared_ptr instances, to co-own a through atomic , where each owner increments a shared counter upon acquisition. The is deleted only when the reference count reaches zero, typically upon the destruction or reassignment of the last owning pointer, using a function. This enables safe sharing without the exclusive constraints, but requires careful use to avoid cycles; the count is maintained in a control block separate from the object itself for across different instances. Unlike raw pointers, which offer no such coordination, shared ownership provides deterministic lifetime management even in multi-owner scenarios. Weak references, exemplified by std::weak_ptr, offer non-owning observation of a without influencing its lifetime or reference count, serving as observers that can detect if the object has been destroyed. A weak_ptr does not increment the shared count and thus cannot prevent deletion by owners, but it can be "locked" to temporarily acquire a shared_ptr for safe access, returning an empty pointer if the resource is gone. This breaks potential circular dependencies in shared ownership graphs and avoids strong reference cycles that could . In contrast to raw pointer aliasing, which might access deleted undetected, weak references enforce runtime checks via methods like expired() to verify validity before use. These semantics collectively promote safe ownership transfer and observation: moves enable exclusive handover without deep copies, while shared and weak models use shallow reference adjustments for efficiency. Raw pointers, by comparison, allow dangerous aliasing where multiple references exist without ownership tracking, often leading to undefined behavior; smart pointers mitigate this through deleted operations and counting, ensuring compile- or runtime-enforced rules.

Standard Smart Pointers

unique_ptr

std::unique_ptr is a smart pointer class in the that provides exclusive semantics for a dynamically allocated object, ensuring automatic deletion of the resource when the pointer goes out of scope. It is defined in the <memory> header and introduced in C++11 to promote safe resource management without the overhead of . The declaration of std::unique_ptr is templated as template<class T, class Deleter = std::default_delete<T>> class unique_ptr;, where T is the type of the managed object and Deleter defaults to std::default_delete<T>, which uses the delete operator for cleanup. For arrays, a specialized form template<class T, class Deleter> class unique_ptr<T[], Deleter>; is available. Key features include its move-only nature, meaning it supports move construction and assignment via std::move but prohibits copying to enforce sole ; it internally stores a raw pointer to the managed resource and invokes the deleter upon destruction or reassignment, preventing memory leaks. In usage, std::unique_ptr is typically initialized with a raw pointer obtained from new, such as std::unique_ptr<int> ptr(new int(42));, which takes immediately. Reassignment occurs through the reset() member function, which deletes the current object if any and assumes of a new one, e.g., ptr.reset(new int(100));. For non-owning access to the raw pointer, the get() method returns it without transferring , allowing temporary use in legacy APIs. Unlike shared_ptr, which permits shared among multiple pointers, std::unique_ptr ensures only one owner at a time. Support for dynamic arrays is provided via the array specialization, enabling management of arrays allocated with new[], for example: std::unique_ptr<int[]> arr(new int[5]);. Elements can be accessed using array subscript syntax like arr[0], and the deleter (defaulting to std::default_delete<T[]>) calls delete[] on destruction. This specialization does not support get() returning a non-const pointer for the first element in the same way as the single-object version. An illustrative example of exclusive ownership transfer is in function parameters, where moving the unique_ptr relinquishes ownership from the caller:

cpp

struct Example { void method() { /* ... */ } }; std::unique_ptr<Example> transfer(std::unique_ptr<Example> ptr) { if (ptr) { ptr->method(); // Use the owned object } return ptr; // Ownership transferred back or to caller } int main() { auto owner = std::make_unique<Example>(); // Assume initialization auto new_owner = transfer(std::move(owner)); // owner now empty // new_owner now owns the resource }

struct Example { void method() { /* ... */ } }; std::unique_ptr<Example> transfer(std::unique_ptr<Example> ptr) { if (ptr) { ptr->method(); // Use the owned object } return ptr; // Ownership transferred back or to caller } int main() { auto owner = std::make_unique<Example>(); // Assume initialization auto new_owner = transfer(std::move(owner)); // owner now empty // new_owner now owns the resource }

This demonstrates how move semantics enable safe transfer without duplication or manual deletion.

shared_ptr

std::shared_ptr is a smart pointer type in the that enables shared ownership of an object through , allowing multiple pointers to manage the same resource cooperatively. It is declared as a class template: template<class T> class shared_ptr;, defined in the <memory> header since C++11. Unlike exclusive ownership models such as std::unique_ptr, std::shared_ptr supports copying, facilitating scenarios where ownership is distributed across multiple components without manual coordination. The core mechanism of std::shared_ptr revolves around a control block that tracks ownership via two counters: a strong reference count for the number of shared_ptr instances managing the object, and a count for non-owning observers. When a shared_ptr is copied or assigned, the strong count is atomically incremented using operations like std::atomic::fetch_add with relaxed to ensure . Conversely, when a shared_ptr goes out of scope or is reset, the strong count is decremented; if it reaches zero, the managed object is destroyed via its associated , and if the weak count is also zero, the control block itself is deallocated. Key features include copy constructibility and assignability, which maintain shared ownership seamlessly, as well as the use_count() member function that returns the current strong reference count for querying ownership status. Additionally, std::shared_ptr integrates with std::enable_shared_from_this<T> to allow objects to create a shared_ptr instance referring to themselves from within their methods, enabling safe sharing from existing managed instances without risking double allocation. For instance, consider the following example where two shared_ptr instances share ownership of an object:

cpp

#include <memory> #include <iostream> struct A { ~A() { std::cout << "Object deleted\n"; } }; int main() { auto sp1 = std::make_shared<A>(); { auto sp2 = sp1; // Copies sp1, strong count becomes 2 std::cout << sp1.use_count() << '\n'; // Outputs: 2 } // sp2 destroyed, strong count decrements to 1 // sp1 destroyed, strong count reaches 0, destructor called } // Outputs: Object deleted

#include <memory> #include <iostream> struct A { ~A() { std::cout << "Object deleted\n"; } }; int main() { auto sp1 = std::make_shared<A>(); { auto sp2 = sp1; // Copies sp1, strong count becomes 2 std::cout << sp1.use_count() << '\n'; // Outputs: 2 } // sp2 destroyed, strong count decrements to 1 // sp1 destroyed, strong count reaches 0, destructor called } // Outputs: Object deleted

This demonstrates automatic lifetime management, as the object is deleted only after the last shared_ptr relinquishes ownership. Regarding thread safety, the reference counts in the control block are managed atomically, allowing concurrent access and modification by multiple threads without data races on the counters themselves. However, std::shared_ptr does not provide any synchronization for the pointed-to object; concurrent modifications to the object require external locking mechanisms to prevent undefined behavior.

weak_ptr

std::weak_ptr is a smart pointer type in the C++ standard library that provides a non-owning reference to an object managed by std::shared_ptr. It is declared as template<class T> class weak_ptr; within the <memory> header and has been part of the standard since C++11. Unlike std::shared_ptr, std::weak_ptr does not participate in the ownership of the pointed-to object and thus cannot extend its lifetime on its own. Construction of a std::weak_ptr requires an existing std::shared_ptr to the same object, typically through assignment or , allowing it to observe the managed resource without incrementing the strong reference count. The primary functionality revolves around the lock() member function, which attempts to create a std::shared_ptr to the observed object; if the object is still alive (i.e., at least one std::shared_ptr exists), it returns a valid std::shared_ptr that temporarily extends the object's lifetime during the scope of the lock; otherwise, it returns an empty std::shared_ptr. This mechanism enables safe access checks without risking dangling pointers. Additionally, std::weak_ptr provides expired(), which returns true if the observed object has been destroyed, offering a lightweight way to query the state without locking. A key use case for std::weak_ptr is breaking circular references in data structures like graphs or caches, where mutual std::shared_ptr ownership could prevent automatic deallocation and lead to memory leaks. For instance, in a parent-child relationship within a , the parent might hold std::shared_ptrs to its children, while each child holds a std::weak_ptr back to the parent; this ensures the children do not keep the parent alive indefinitely, allowing proper cleanup when the parent's reference count reaches zero. The following example illustrates a std::weak_ptr observing an object managed by std::shared_ptr and checking for expiration before access:

cpp

#include <memory> #include <iostream> int main() { std::weak_ptr<int> weak; { auto strong = std::make_shared<int>(42); weak = strong; // weak_ptr observes the shared_ptr-managed int if (auto locked = weak.lock()) { std::cout << "Value: " << *locked << std::endl; // Outputs: Value: 42 } } // strong goes out of scope, destroying the object if (weak.expired()) { std::cout << "Object has expired." << std::endl; // Outputs: Object has expired. } if (auto locked = weak.lock()) { // This block is not entered } else { std::cout << "No valid shared_ptr available." << std::endl; // Outputs: No valid shared_ptr available. } }

#include <memory> #include <iostream> int main() { std::weak_ptr<int> weak; { auto strong = std::make_shared<int>(42); weak = strong; // weak_ptr observes the shared_ptr-managed int if (auto locked = weak.lock()) { std::cout << "Value: " << *locked << std::endl; // Outputs: Value: 42 } } // strong goes out of scope, destroying the object if (weak.expired()) { std::cout << "Object has expired." << std::endl; // Outputs: Object has expired. } if (auto locked = weak.lock()) { // This block is not entered } else { std::cout << "No valid shared_ptr available." << std::endl; // Outputs: No valid shared_ptr available. } }

The lifetime of a std::weak_ptr is tied to the underlying object it observes: it becomes expired when all associated std::shared_ptr instances are destroyed or reset, at which point attempts to lock it will fail, signaling that the resource is no longer available. This design integrates with the reference counting model of std::shared_ptr, where std::weak_ptr contributes only to a weak count that does not influence destruction but allows observers to detect when the strong count drops to zero.

Creation and Manipulation

Factory Functions

Factory functions provide a safe and efficient means to create instances of smart pointers, particularly std::unique_ptr and std::shared_ptr, by directly constructing the managed object without exposing raw pointers. These utilities, introduced in the C++ standard library, ensure exception safety during object creation and, in the case of std::make_shared, optimize memory allocation. The function std::make_shared, available since C++11, constructs an object of type T and returns a std::shared_ptr<T> managing it. Its template signature is template<class T, class... Args> shared_ptr<T> make_shared(Args&&... args);, where args are forwarded to the constructor of T. This function performs a single memory allocation for both the object and the shared pointer's control block, which tracks reference counts, offering improved efficiency over the two separate allocations required by std::shared_ptr<T>(new T(args...)). Additionally, it provides strong : if the constructor of T throws an exception, no memory is leaked, as the allocation is rolled back. Since , std::make_shared also supports arrays, both with unknown bounds (e.g., T[]) and known bounds (e.g., T[N]), via overloads that value-initialize or fill with a specified value, or use std::make_shared_for_overwrite for default initialization to skip unnecessary work when overwriting. This extends the single-allocation efficiency to arrays. Introduced in , std::make_unique similarly constructs an object of type T and wraps it in a std::unique_ptr<T>, with the template template<class T, class... Args> unique_ptr<T> make_unique(Args&&... args);. By avoiding explicit raw new expressions, it promotes safer and more idiomatic code, particularly in complex expressions where order of evaluation could expose raw pointers temporarily, and ensures consistent initialization semantics. Like std::make_shared, it ensures . An overload for arrays, template<class T> unique_ptr<T> make_unique(std::size_t size);, supports dynamic arrays of unknown bound since , value-initializing the elements (invoking default constructors for class types and zero-initializing built-in types). These factory functions enhance code safety and performance. For std::shared_ptr, the consolidated allocation reduces overhead and improves cache locality, which can lead to measurable speedups in reference-counting operations. Both functions promote idiomatic C++ by eliminating raw new expressions, aligning with guidelines to prefer smart pointer factories for transfer. For instance, consider creating a simple integer wrapper:

cpp

#include <memory> #include <iostream> struct IntWrapper { int value; IntWrapper(int v) : value(v) {} }; int main() { // Using make_unique (C++14) auto up = std::make_unique<IntWrapper>(42); std::cout << up->value << std::endl; // Outputs: 42 // Using make_shared (C++11) auto sp = std::make_shared<IntWrapper>(42); std::cout << sp->value << std::endl; // Outputs: 42 }

#include <memory> #include <iostream> struct IntWrapper { int value; IntWrapper(int v) : value(v) {} }; int main() { // Using make_unique (C++14) auto up = std::make_unique<IntWrapper>(42); std::cout << up->value << std::endl; // Outputs: 42 // Using make_shared (C++11) auto sp = std::make_shared<IntWrapper>(42); std::cout << sp->value << std::endl; // Outputs: 42 }

In contrast, the pre-factory approach with raw pointers can risk leaks if an exception occurs between allocation and ownership transfer in multi-step operations. Despite their advantages, these functions have limitations. There is no standard std::make_weak for directly creating std::weak_ptr instances, as weak_ptr must be constructed from an existing std::shared_ptr to observe shared ownership without participating in it. For std::make_unique, array support is restricted to unknown bounds; fixed-size arrays cannot be created via this factory. In contrast, std::make_shared supports both since C++20. Elements in array overloads of std::make_unique are value-initialized, while C++20's make_unique_for_overwrite variants use default initialization (skipping zero-initialization for built-in types and PODs) for efficiency in overwrite scenarios.

Type Conversions and Assignments

Smart pointers in C++ facilitate safe ownership transfers through specific mechanisms for moves, conversions, and assignments, ensuring resource management without leaks or double deletions. For std::unique_ptr, ownership is exclusively held and can only be transferred via move semantics using std::move, which relinquishes control from the source pointer to the destination. This move operation to another std::unique_ptr of compatible type (or to a raw pointer via release()) effectively releases ownership from the original, leaving it in a null state. Conversions between smart pointer types promote or adjust ownership models without violating exclusivity. A std::unique_ptr can be converted to a std::shared_ptr by explicitly constructing the latter with the moved std::unique_ptr, promoting exclusive ownership to shared ownership while transferring the managed resource. Similarly, a std::shared_ptr can be converted to a std::weak_ptr via direct construction, creating a non-owning observer that does not increment the reference count but allows later upgrade to shared ownership if the resource persists. These conversions require type compatibility, such as T* being convertible to the target pointer type, and are designed to prevent unintended sharing or loss of control. Assignments for smart pointers vary by type to enforce their semantics. For std::unique_ptr, assignment is move-only; the reset() member function allows replacing the managed object with a new raw pointer, deleting the previous one if it existed. In contrast, std::shared_ptr supports copy assignment via the operator=, which increments the reference count of the source and decrements the target's if necessary, enabling multiple owners. Direct assignment from raw pointers is not supported; instead, use reset() for unique or constructors for shared. Type safety rules govern these operations to avoid misuse. Downcasts between smart pointers (e.g., from base to derived) are not permitted without explicit template specialization for derived-to-base conversions; implicit upcasts to base types are allowed only if the base has a virtual destructor to ensure proper cleanup. Raw pointers should not be returned from functions managing resources except via get() for temporary access (without ownership transfer) or release() when explicitly handing off ownership, as this maintains exception safety. A practical example illustrates transferring ownership from exclusive to shared: consider a function that returns a std::unique_ptr to a dynamically allocated object, which can then be moved into a std::shared_ptr for broader use.

cpp

std::unique_ptr<int> create_int() { return std::unique_ptr<int>(new int(42)); } void example() { auto up = create_int(); // Exclusive ownership std::shared_ptr<int> sp(std::move(up)); // Promote to shared; up is now null // sp now shares ownership; up.get() returns nullptr }

std::unique_ptr<int> create_int() { return std::unique_ptr<int>(new int(42)); } void example() { auto up = create_int(); // Exclusive ownership std::shared_ptr<int> sp(std::move(up)); // Promote to shared; up is now null // sp now shares ownership; up.get() returns nullptr }

This pattern leverages move semantics for efficiency and safety, avoiding copies of the underlying resource.

Extensions and Alternatives

Custom Deleters and Traits

Smart pointers in C++ can be extended with custom deleters to manage resources beyond heap-allocated memory, such as files, network sockets, or specialized allocations like custom heaps. For std::unique_ptr, the deleter is specified as a second template parameter, allowing it to be a function pointer, functor, or lambda that defines the cleanup operation invoked upon destruction or reset. This enables precise control over resource lifetime; for instance, std::unique_ptr<FILE, decltype(&std::fclose)*> file_ptr(std::fopen("example.txt", "r"), &std::fclose); automatically closes the file handle when the pointer goes out of scope. Similarly, std::shared_ptr constructors accept a custom deleter, which is stored and executed when the last reference is destroyed, ensuring shared ownership applies to non-memory resources like open sockets via close or custom heap deallocators. The default deleter, std::default_delete<T>, invokes operator delete for single objects or operator delete[] for arrays through its partial specialization. Custom deleters are particularly useful for RAII management of heterogeneous resources. For file handles, the deleter calls fclose to prevent leaks in I/O operations; for sockets, it invokes close to release network connections; and for custom heaps, it integrates with domain-specific deallocation routines, avoiding manual cleanup and reducing error-prone code. Specializing std::default_delete is permitted but restricted to preserving standard semantics, such as the array specialization that ensures delete[] is used for dynamic arrays, preventing incomplete type issues during construction while enforcing correct deallocation at destruction. Users can provide partial specializations for incomplete types, but they must ultimately call delete to maintain compatibility with std::unique_ptr's default behavior. Traits like std::enable_shared_from_this<T> enhance smart pointers for polymorphic scenarios, allowing objects managed by std::shared_ptr to safely produce additional shared_ptr instances pointing to themselves via shared_from_this(). This trait, implemented as a CRTP base class, stores a weak_ptr internally to avoid circular references and supports hierarchies where derived classes need to return shared ownership without raw pointer risks. For example, in event-driven systems, a base class deriving from enable_shared_from_this enables polymorphic event handlers to share their this pointer securely. Since , std::shared_ptr supports stateful deleters, where the deleter object (including any internal state like configuration parameters) is copied into the control block alongside the reference count and allocator. This allows deleters to maintain context, such as details or resource-specific flags, during shared lifetime management without type erasure overhead in simple cases. For GPU resources, like memory allocations, a custom deleter can wrap cudaFree:

cpp

struct CudaDeleter { void operator()(void* ptr) { cudaError_t err = cudaFree(ptr); if (err != cudaSuccess) { // [Handle](/page/Handle) error } } }; void* ptr; cudaMalloc(&ptr, size); std::unique_ptr<void, CudaDeleter> gpu_ptr(ptr, CudaDeleter{});[](https://stackoverflow.com/questions/47383386/use-of-unique-ptr-and-cudamalloc)

struct CudaDeleter { void operator()(void* ptr) { cudaError_t err = cudaFree(ptr); if (err != cudaSuccess) { // [Handle](/page/Handle) error } } }; void* ptr; cudaMalloc(&ptr, size); std::unique_ptr<void, CudaDeleter> gpu_ptr(ptr, CudaDeleter{});[](https://stackoverflow.com/questions/47383386/use-of-unique-ptr-and-cudamalloc)

This ensures automatic GPU memory release upon scope exit, integrating seamlessly with host-side RAII.

Non-Standard Smart Pointers

One notable example of a deprecated smart pointer in C++ is std::auto_ptr, introduced in the C++98 standard to provide exclusive semantics through transfer-on-copy behavior, where copying the pointer invalidates the original. This design made auto_ptr unsuitable for use in standard containers like std::vector, as it violated the copy constructibility requirements by transferring ownership rather than it. Deprecated in C++11 due to these limitations and the introduction of superior alternatives like std::unique_ptr, auto_ptr was fully removed in C++17 to streamline the language and encourage modern practices. The Boost library extends smart pointer functionality with types like boost::intrusive_ptr, which manages shared ownership by relying on a reference count embedded directly within the managed object, requiring the user to implement increment and decrement functions (typically named intrusive_ref_count or similar). This intrusive approach avoids the overhead of external control blocks used in std::shared_ptr, making it suitable for performance-sensitive scenarios where objects already maintain their own counts, such as COM interfaces. Another Boost extension, boost::local_shared_ptr, provides thread-local shared ownership without atomic operations, reducing synchronization costs compared to std::shared_ptr in single-threaded contexts. Custom implementations of smart pointers have emerged to address specific needs beyond the , such as observer pointers that hold non-owning references without influencing the lifetime of the observed object, preventing issues like dangling pointers in observer patterns. The library, part of the framework from Andrei Alexandrescu's , offers policy-based smart pointers (Loki::SmartPtr) that allow customization of ownership, storage, and checking behaviors through template policies, enabling tailored solutions like thread-safe or null-rejecting variants. In other languages, concepts analogous to C++ weak pointers appear in Java's WeakReference, which holds a non-strong reference to an object without preventing garbage collection, differing from C++'s std::weak_ptr by relying on a collector rather than manual cycle breaking. Rust's Rc and Arc provide reference-counted shared ownership similar to std::shared_ptr, with Rc for single-threaded use and Arc for atomic multi-threaded scenarios. Non-standard smart pointers are typically employed in rare cases, such as maintaining compatibility with legacy code using auto_ptr during migration or optimizing in domains requiring intrusive counting, like real-time systems where intrusive_ptr minimizes allocation overhead.

Implementation and Best Practices

Performance Considerations

Smart pointers in C++ are designed to minimize runtime and overhead while providing automatic , but their performance characteristics vary significantly between types. The std::unique_ptr imposes virtually no additional overhead compared to raw pointers, as it stores only the pointer itself (typically 8 bytes on 64-bit systems) and performs deletion at the end of its scope without . In contrast, std::shared_ptr introduces measurable costs due to its shared ownership model, which relies on a separate control block to manage counts. The memory footprint of std::shared_ptr is typically 16 bytes on 64-bit architectures, consisting of a pointer to the managed object and a pointer to the control block. The control block itself adds 16-24 bytes (or more with custom deleters), including atomic counters for strong and weak references, and is allocated separately unless using std::make_shared. This shared allocation amortizes the cost across multiple shared_ptr instances but still incurs indirection and potential cache misses when accessing the control block. Reference counting in std::shared_ptr involves atomic increment and decrement operations on the control block's counters, using std::memory_order_relaxed for efficiency. Uncontended atomic increments cost approximately 5-10 cycles on x86 processors, primarily due to the LOCK prefix and , though this can rise to 10-25 times the cost of non-atomic operations under contention. These operations occur on construction, copying, and destruction, adding overhead to frequent pointer manipulations but negligible impact for long-lived objects. Benchmarks illustrate these costs in practical scenarios. For allocation and deallocation of 100 million instances, std::unique_ptr performs comparably to raw new/delete, while std::shared_ptr is roughly twice as slow without optimizations; using std::make_shared reduces this to about 10% overhead by colocating the object and control block in a single allocation. In containers like std::vector<std::shared_ptr<T>>, indirection exacerbates cache misses during sequential or ; for example, updating 80,000 objects via pointers can be up to 2.66 times slower than direct access in std::vector<T> due to scattered layout, with shared_ptr adding further reference-counting latency. To mitigate these overheads, developers should prefer std::unique_ptr for exclusive , as it avoids all reference-counting costs. For shared ownership, std::make_shared is recommended over separate to halve allocation calls, and custom allocators can optimize control block placement for high-volume scenarios. Using std::weak_ptr helps break ownership cycles that could otherwise lead to persistent memory use, indirectly preserving performance by enabling timely deallocation. In multithreaded contexts, the atomic reference counts ensure but introduce overhead; non-atomic alternatives are unsuitable due to race conditions.

Common Pitfalls and Guidelines

One common pitfall with smart pointers arises from circular references in std::shared_ptr, where two or more objects each hold a std::shared_ptr to one another, preventing the reference count from reaching zero and causing memory leaks. To mitigate this, std::weak_ptr should be used in at least of the reference to break the cycle without owning the resource. Mixing smart pointers with raw pointers often leads to double deletion or , such as when a raw pointer is passed to a smart pointer constructor after already being managed elsewhere. For instance, converting a raw pointer to a std::shared_ptr without ensuring exclusive can result in the destructor being called twice if the raw pointer is also deleted manually. Forgetting to handle moves properly, especially when returning smart pointers from functions, can introduce unnecessary copies or exceptions that leak resources; always rely on move semantics for efficiency in such cases. Guidelines recommend always using factory functions like std::make_unique and std::make_shared for creating smart pointers, as they perform a single allocation and avoid potential leaks from exceptions during construction. Prefer std::unique_ptr over std::shared_ptr for exclusive ownership to minimize overhead from . Avoid raw new and delete entirely in favor of smart pointers to enforce automatic . When using std::weak_ptr, always check the result of lock() before dereferencing to ensure the resource still exists, as it may have been deleted. In C++23, new smart pointer types such as std::out_ptr and std::inout_ptr provide safer ways to interface with C APIs that expect raw pointers, helping to prevent common errors in mixed-language code. For debugging, tools like can detect memory leaks from smart pointer misuse, such as unreleased cycles, by tracking allocations and deallocations. Static analysis tools, including those enforcing C++ Core Guidelines, help identify ownership violations like unnecessary smart pointer parameters. In modern C++ ( and later), integrate smart pointers with ranges for safe iteration over owned resources and with coroutines for managing awaitable states, but avoid them in performance-critical hot paths due to potential overhead from atomic operations in std::shared_ptr. As noted in considerations, this ensures safety without undue cost in non-critical code. Example Refactor from Raw to Smart Pointers: Consider legacy using raw pointers, which risks and double deletes:

cpp

// Risky raw pointer [code](/page/Code) Widget* create_widget() { Widget* w = new Widget(); // ... use w ... return w; // Caller must remember to delete } void process(Widget* w) { if (w) { // ... process ... delete w; // Potential double delete if forgotten elsewhere } }

// Risky raw pointer [code](/page/Code) Widget* create_widget() { Widget* w = new Widget(); // ... use w ... return w; // Caller must remember to delete } void process(Widget* w) { if (w) { // ... process ... delete w; // Potential double delete if forgotten elsewhere } }

Refactored with smart pointers to avoid these pitfalls:

cpp

// Safe smart pointer version std::unique_ptr<Widget> create_widget() { return std::make_unique<Widget>(); // Automatic cleanup, no [leak](/page/Leak) on exception } void process(std::unique_ptr<Widget> w) { // Transfers ownership if (w) { // ... process ... // No manual delete needed } // w destroyed here, Widget deleted automatically }

// Safe smart pointer version std::unique_ptr<Widget> create_widget() { return std::make_unique<Widget>(); // Automatic cleanup, no [leak](/page/Leak) on exception } void process(std::unique_ptr<Widget> w) { // Transfers ownership if (w) { // ... process ... // No manual delete needed } // w destroyed here, Widget deleted automatically }

This refactor ensures exclusive ownership with std::unique_ptr, eliminates manual deletion, and prevents leaks even if exceptions occur.

References

  1. https://en.cppreference.com/book/intro/smart_pointers
  2. https://learn.microsoft.com/en-us/cpp/cpp/smart-pointers-modern-cpp?view=msvc-170
  3. https://en.cppreference.com/w/cpp/memory
  4. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r6.pdf
  5. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1450.html
  6. https://en.cppreference.com/w/cpp/memory/shared_ptr
  7. https://en.cppreference.com/w/cpp/memory/unique_ptr
  8. http://www.aristeia.com/BookErrata/auto_ptr-update.html
  9. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4168
  10. https://www.boost.org/doc/libs/1_85_0/libs/smart_ptr/doc/html/smart_ptr.html
  11. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2853.pdf
  12. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3050.html
  13. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4168.html
  14. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2273r3.pdf
  15. https://en.cppreference.com/w/cpp/language/raii.html
  16. https://www.stroustrup.com/bs_faq2.html#finally
  17. https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#e6-use-raii-to-prevent-leaks
  18. https://en.cppreference.com/w/cpp/memory/weak_ptr
  19. https://en.cppreference.com/w/cpp/memory/default_delete
  20. https://en.cppreference.com/w/cpp/memory/unique_ptr/make_unique
  21. https://en.cppreference.com/w/cpp/memory/shared_ptr/make_shared
  22. https://learn.microsoft.com/en-us/cpp/cpp/how-to-create-and-use-unique-ptr-instances?view=msvc-170
  23. https://en.cppreference.com/w/cpp/memory/unique_ptr/release
  24. https://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr.unique_ptr
  25. https://en.cppreference.com/w/cpp/memory/weak_ptr/weak_ptr.shared_ptr
  26. https://en.cppreference.com/w/cpp/memory/unique_ptr/reset
  27. https://stackoverflow.com/questions/29614775/smart-pointer-to-manage-socket-file-descriptor
  28. https://devblogs.microsoft.com/cppblog/c17-feature-removals-and-deprecations/
  29. https://www.cppstories.com/2017/05/cpp17-details-fixes-deprecation/
  30. https://softwareengineering.stackexchange.com/questions/291141/how-to-handle-design-changes-for-auto-ptr-deprecation-in-c11
  31. https://www.boost.org/doc/libs/1_38_0/libs/smart_ptr/intrusive_ptr.html
  32. https://baptiste-wicht.com/posts/2011/11/boost-intrusive_ptr.html
  33. https://www.boost.org/libs/smart_ptr
  34. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf
  35. https://ptgmedia.pearsoncmg.com/images/0201704315/samplechapter/alexan07.pdf
  36. https://www.cs.fsu.edu/~lacher/lectures/Output/loki7/index.html?%24%24%24toc.html%24%24%24
  37. https://stackoverflow.com/questions/16613545/is-there-in-c-something-similar-to-weak-reference-in-java
  38. https://stackoverflow.com/questions/67063641/are-rust-smart-pointers-stdrcrc-and-stdsyncarc-analogous-to-the-c-smar
  39. https://www.modernescpp.com/index.php/memory-and-performance-overhead-of-smart-pointer/
  40. https://stackoverflow.com/questions/6826402/why-is-the-size-of-make-shared-two-pointers
  41. https://alexanderhoughton.co.uk/blog/c-unique-shared-ptr-custom-deleters/
  42. https://www.modernescpp.com/index.php/std-shared-ptr/
  43. https://fgiesen.wordpress.com/2014/08/18/atomics-and-contention/
  44. https://stackoverflow.com/questions/25780826/whats-the-overhead-from-shared-ptr-being-thread-safe
  45. https://www.cppstories.com/2014/05/vector-of-objects-vs-vector-of-pointers/
  46. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-cycle
  47. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-raw
  48. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-unique
  49. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-make_shared
  50. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-delete
  51. https://www.sandordargo.com/blog/2022/12/07/inout_ptr-and-out_ptr
  52. https://valgrind.org/docs/manual/mc-manual.html
  53. https://learn.microsoft.com/en-us/cpp/code-quality/code-analysis-for-cpp-corecheck?view=msvc-170
  54. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-shared
  55. https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf26-use-a-unique_ptrt-to-transfer-ownership-where-a-pointer-is-needed
Add your contribution
Related Hubs
User Avatar
No comments yet.