80. Shared Pointer Ownership
You are working with a data object that stores values read from input.
This data must be accessed by both main() and another function.
If the object is owned by only one place, it may be destroyed too early.
To prevent this, ownership must be shared.
Your task is to use std::shared_ptr so that both main() and a function own the same object, ensuring the data remains valid until both are done using it.
What You Must Do:
- Store input values inside a class object
- Create the object using
std::shared_ptr - Pass the object to a function by value to share ownership
- Use the object in both places
- Ensure the destructor runs only once, at the very end
Program Flow:
- Read
N - Create a data object that stores
Nintegers - Read
Nvalues into the object - Pass the object to a function that prints the data
- Print the data again in
main() - Destroy the object only after both uses are complete
Example Input:
3
10 20 30
Example Output:
Data created
Printed in function
10 20 30
Printed in main
10 20 30
Data destroyed
Constraints:
Nranges from 1 to 100- Data must be stored inside a class
- Ownership must be shared using
std::shared_ptr - Do not manually manage object lifetime
- Output format must match exactly
Raw pointers (T* ptr = new T()) impose a heavy burden: you must manually call delete, otherwise you get memory leaks. If you delete too early, you get dangling pointer crashes.
Smart Pointers are wrapper classes that own the raw pointer. They automatically call delete (or a custom cleanup function) when the pointer goes out of scope, using the RAII pattern.
They live in the <memory> header.
Types & Usage
1. std::unique_ptr (The Embedded Standard)
Represents exclusive ownership. Only one pointer can own the resource.
- Copying: Banned (Compiler error).
- Moving: Allowed (Transfers ownership).
- Overhead: Zero. It is exactly the same size as a raw pointer.
#include <memory>
void setup_sensor() {
// Create unique pointer (Preferred syntax: make_unique)
std::unique_ptr<Sensor> s = std::make_unique<Sensor>(10);
s->init(); // Use -> just like a raw pointer
// No delete needed!
// When function returns, 's' is destroyed -> calls ~Sensor() -> frees memory.
}2. std::shared_ptr (Reference Counted)
Represents shared ownership. Multiple pointers can point to the same object.
- It maintains a Reference Count. Every time you copy the pointer, count
+1. When a pointer dies, count-1. - The memory is freed only when the count hits 0.
std::shared_ptr<Data> p1 = std::make_shared<Data>();
{
std::shared_ptr<Data> p2 = p1; // Count = 2
} // p2 dies. Count = 1. Data still exists.
// p1 dies. Count = 0. Data deleted.3. std::weak_ptr
A non-owning observer of a shared_ptr. It doesn't increase the reference count. Used to break Circular Dependencies (A points to B, B points to A) which cause memory leaks.
Memory Layout & Overhead
| Feature | unique_ptr | shared_ptr |
|---|---|---|
| Ownership | Solo (1 owner). | Shared (N owners). |
| Size | sizeof(void*) (4 bytes). | 2 * sizeof(void*) (Ptr + Control Block). |
| Performance | Fast (Inline calls). | Slower (Atomic Ref-Counting). |
| Embedded Use | Recommended (99% of cases). | Avoid (unless necessary). |
Relevance in Embedded/Firmware
1. unique_ptr for Drivers
Hardware drivers usually have single ownership. A UART object manages a specific hardware block.
Using unique_ptr<UART> ensures that if the driver is replaced or shut down, the cleanup (destructor) happens automatically.
2. Custom Deleters (No Heap Required)
Smart pointers are often associated with new/delete (Heap), but they can manage any resource. You can teach a unique_ptr to call a specific function (like fclose or free_buffer) instead of delete.
// A pointer that calls 'close_file' instead of 'delete'
auto deleter = [](FILE* f) { fclose(f); };
std::unique_ptr<FILE, decltype(deleter)> file_ptr(fopen("log.txt", "w"), deleter);
// When file_ptr goes out of scope, fclose() is called automatically.3. Factory Patterns
Factories that return std::unique_ptr<Base> allow you to return different derived driver types safely without worrying about who is responsible for deleting them.
Common Pitfalls (Practical Tips)
| Pitfall | Details |
|---|---|
❌ shared_ptr Overhead | shared_ptr allocates a "Control Block" on the heap to store the counter. This causes Heap Fragmentation and involves atomic instructions (slow) to update the count. Avoid in tight loops. |
❌ auto_ptr | Deprecated and removed in C++17. Never use it. It had broken copy semantics. Use unique_ptr instead. |
❌ get() misuse | ptr.get() returns the raw pointer. Be careful not to manually delete this raw pointer, or the smart pointer will double-free it later. |
✅ make_unique | Always use std::make_unique<T>() instead of new T(). It’s safer (prevents leaks if constructor throws) and cleaner. |