In the case of using a std::unique_ptr to automatically deallocate memory upon exiting a scoped block, why not just use the stack?

Question

This is a great answer about smart pointers, such as unique pointers: What is a smart pointer and when should I use one?.

Here is an example they provide as the simplest use of a unique pointer:

void f()
{
    {
       std::unique_ptr<MyObject> ptr(new MyObject(my_constructor_param));
       ptr->DoSomethingUseful();
    } // ptr goes out of scope -- 
      // the MyObject is automatically destroyed.

    // ptr->Oops(); // Compile error: "ptr" not defined
                    // since it is no longer in scope.
}

However, this begs the question: in cases such as this, where the goal is to simply delete the object (free the memory) the unique pointer points to when it goes out of scope, why not just put the whole object on the stack instead, like this??

void f()
{
    {
       MyObject myobj(my_constructor_param);
       myobj.DoSomethingUseful();
    } // myobj goes out of scope -- 
      // and is automatically destroyed.

    // myobj.Oops(); // Compile error: "myobj" not defined
                     // since it is no longer in scope.
}

It seems to me the only logic can be that some objects are so stinking large they may overflow the stack, as stacks seem to be limited to a few dozen KB to a few MB (C/C++ maximum stack size of program), whereas a heap can be hundreds of GB!

What's the logic? Give me some insight here into this seemingly unnecessary use case of the unique pointer. What am I missing?

Related:

1. "Another feature of the stack to keep in mind, is that there is a limit (varies with OS) on the size of variables that can be stored on the stack. This is not the case for variables allocated on the heap." (https://gribblelab.org/CBootCamp/7_Memory_Stack_vs_Heap.html)

Answer 1

While this is not a terrible useful example per-se, it becomes with some slight variations.

1. Polymorphism

struct Base { void blah() { std::cout << "Base\n";}};
struct Derived : Base { void blah() {std::cout << "Derived\n";}};

void blub(bool which) { 
    std::unique_ptr<Base> ptr = which ? new Base : new Derived;
    ptr->blah();
}

2. Non-standard deleter

{ 
    auto close = [] (FILE* fp) { fclose(fp);};
    std::unique_ptr<FILE, decltype(close)> ptr(fopen("name"), close);
} // closes file

3. Dynamic Array (you can arguably use a vector)

{ 
    std:: unique_ptr<int[]> ptr( new int [n]); 
    // From C++14 on, prefer if it is no problem to value-initialize the array
    auto ptr = std::make_unique<int[]>(n);
    // From C++20 on, there is no reason for the naked new
    auto ptr = std::make_unique_for_overwrite<int[]>(n);
    // is equivalent to the first line
}

EDIT: This also reasonable for big arrays, even if the size is know at compile time. If the size of the array would be really big (and this should be very, very rare) and you really do not want to run the risk of a stack overflow, this would be a safer possibility. But very probably std::vector is the better alternative still. Only if your object type is neither moveable nor copyable, the vector will have problems (since it cannot reallocate itself if necessary, and hence you can call basically no modifying member function).

4. Conditional creation of an object. (Only in C++11 and 14, after that use std::optional)

void blah (bool smth)
{
    std::unique_ptr<T> opt;
    if (smth) {
        opt = std::unique_ptr<T>(new T);
    }
}

Answer 2

If you want to return a pointer to an object, then without smart pointers, we had to do this:

MyClass* someFunc() {
    MyClass* myObjPtr = new MyClass();
    .
    .
    return myObjPtr;
}

void otherFunc() {
    MyClass* myPtr = someFunc();
    .
    .
    delete myPtr;  // delete explicitely before return.
    return;
}

Instead if we use smart pointers, we can do this:

typedef std::shared_ptr<MyClass> MyClassPtr;

MyClassPtr someFunc() {
    MyClassPtr myObjPtr(new MyClass());
    .
    .
    return myObjPtr;
}

void otherFunc() {
    MyClassPtr myPtr = someFunc();
    .
    .
    return;  // when smart pointer goes out of scope,
    // the heap allocated object which it contains is deallocated properly.
}

Answer 3

Size is not the primary concern, although it may be important if you have recursion, for example (I saw a library allocating 64 KiB buffer on stack, in a recursive function. But Musl provides 128 KiB stacks [to make threads lightweight], so...) But the object may be polymorphic, and not even created “right there” but rather returned from some function (as a pointer); unique_ptr may be handy to store that.

Besides that, unique_ptr (unlike auto_ptr AFAIK) is not restricted to on-stack usage. It can be a class member as well. Also it is not required to actually store anything, you may assign and reset it at any time.

Moreover, it is not restricted to C++ classes, you can store anything requiring cleanup there, like file descriptor or FILE*, for example.