79. Unique Pointer Custom Deleter
In embedded and firmware-oriented C++ systems, objects are frequently created inside factory functions and manage multiple dynamically allocated resources internally. Such objects often cannot rely on a default destructor and instead must be cleaned up using a specific cleanup routine to ensure deterministic and correct resource release.
You are given:
- A class that dynamically allocates two internal buffers
- A factory function that creates the object dynamically
- A custom cleanup function that must be used to destroy the object correctly
Your task is to use std::unique_ptr with a custom deleter so that:
- The object is created inside a function
- Ownership is transferred safely to the caller
- Cleanup happens automatically when the object goes out of scope
- The custom cleanup function is invoked exactly once
- No manual calls to
deleteorcleanup()are made
Program Flow:
- Read integer
N - Call a factory function that dynamically allocates and returns an object
- Store the returned object in a
std::unique_ptrwith a custom deleter - Read
Ninteger values and store them in the object - Print the stored values
- Exit the scope
- Custom cleanup must execute automatically
Input:
- Integer
N(1 ≤ N ≤ 100) Nspace-separated integers on the next line
Notes:
- Values are stored in
uint8_tbuffers
(values outside the range 0–255 are truncated modulo 256) - Object allocation must occur inside the factory function
- Do not manually call
deleteorcleanup()
Output:
- One line containing the stored values separated by spaces
- A newline
The exact text:
Object cleaned
Example Input:
3
10 20 30 Example Output:
10 20 30
Object cleaned
Constraints:
1 ≤ N ≤ 100- The object owns multiple dynamically allocated members
- Cleanup must occur through the provided cleanup function
- 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. |