Prev Problem
Next Problem
Task
Discussion
Submissions
Solution
Report

77. unique_ptr Ownership Consume

In modern C++, function signatures communicate ownership intent.
A function that takes ownership of a resource must make that intent explicit in its parameter type.

You are given a program where a buffer is managed by std::unique_ptr.
The buffer must be consumed by a function, meaning ownership transfers to the function and the caller must no longer own it.

Your task is to fix the function API and the call site so that ownership transfer is explicit and correct.

This problem is about API design, not mechanics.

Program Flow:

  1. Read N
  2. Create a unique_ptr that owns a buffer of N bytes
  3. Call a function that consumes the buffer
  4. The function prints the buffer
  5. After the call, the caller must have no ownership

Example Input:

4
10 20 30 40

Example Output:

10 20 30 40
No data

Constraints:

  • N ranges from 1 to 100
  • Ownership must be transferred to the function
  • The function must clearly express ownership transfer in its signature
  • Output format must match exactly

 

 

 

Need Help? Refer to the Quick Guide below

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

Featureunique_ptrshared_ptr
OwnershipSolo (1 owner).Shared (N owners).
Sizesizeof(void*) (4 bytes).2 * sizeof(void*) (Ptr + Control Block).
PerformanceFast (Inline calls).Slower (Atomic Ref-Counting).
Embedded UseRecommended (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)

PitfallDetails
❌ shared_ptr Overheadshared_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_ptrDeprecated and removed in C++17. Never use it. It had broken copy semantics. Use unique_ptr instead.
❌ get() misuseptr.get() returns the raw pointer. Be careful not to manually delete this raw pointer, or the smart pointer will double-free it later.
✅ make_uniqueAlways use std::make_unique<T>() instead of new T(). It’s safer (prevents leaks if constructor throws) and cleaner.