std::make_unique<T> vs reset(new T)

Question

I want to ask a question about memory leaks in constructor. Let's consider a class:

 class Foo
 {
   public:
      Foo(){ throw 500;} 
 };

What is the difference between

std::unique_ptr<Foo> l_ptr = std::make_unique<Foo>();

and

std::unique_ptr<Foo> l_ptr;
l_ptr.reset(new Foo());

In my opinion a solution with make_unique should protect me from memory leak but in both situations I got the same valgrind result:

$ valgrind --leak-check=full ./a.out
==17611== Memcheck, a memory error detector
==17611== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==17611== Using Valgrind-3.11.0 and LibVEX; rerun with -h for copyright info
==17611== Command: ./a.out
==17611== 
terminate called after throwing an instance of 'int'
==17611== 
==17611== Process terminating with default action of signal 6 (SIGABRT)
==17611==    at 0x5407418: raise (raise.c:54)
==17611==    by 0x5409019: abort (abort.c:89)
==17611==    by 0x4EC984C: __gnu_cxx::__verbose_terminate_handler() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17611==    by 0x4EC76B5: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17611==    by 0x4EC7700: std::terminate() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17611==    by 0x4EC7918: __cxa_throw (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17611==    by 0x40097B: Foo::Foo() (in /home/rungo/Repositories/test/a.out)
==17611==    by 0x4008DC: main (in /home/rungo/Repositories/test/a.out)
==17611== 
==17611== HEAP SUMMARY:
==17611==     in use at exit: 72,837 bytes in 3 blocks
==17611==   total heap usage: 4 allocs, 1 frees, 72,841 bytes allocated
==17611== 
==17611== 132 bytes in 1 blocks are possibly lost in loss record 2 of 3
==17611==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==17611==    by 0x4EC641F: __cxa_allocate_exception (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==17611==    by 0x400963: Foo::Foo() (in /home/rungo/Repositories/test/a.out)
==17611==    by 0x4008DC: main (in /home/rungo/Repositories/test/a.out)
==17611== 
==17611== LEAK SUMMARY:
==17611==    definitely lost: 0 bytes in 0 blocks
==17611==    indirectly lost: 0 bytes in 0 blocks
==17611==      possibly lost: 132 bytes in 1 blocks
==17611==    still reachable: 72,705 bytes in 2 blocks
==17611==         suppressed: 0 bytes in 0 blocks
==17611== Reachable blocks (those to which a pointer was found) are not shown.
==17611== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==17611== 
==17611== For counts of detected and suppressed errors, rerun with: -v
==17611== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
[1]    17611 abort (core dumped)  valgrind --leak-check=full ./a.out

It is the same when I use clang++ and g++. I found here: https://isocpp.org/wiki/faq/exceptions#ctors-can-throw the sentence:

Note: if a constructor finishes by throwing an exception, the memory associated with the object itself is cleaned up — there is no memory leak.

My question is why we have a leak in this situation and why make_unique is not preventing a leak (doeas it means that there is no dofference between make_unique and reset(new ...)?

Answer 1

Are you catching the exception? When catching the exception, valgrind (compiling with g++ 6.2 -g) detects no leaks both with make_unique and reset.

int main() try
{
#if TEST_MAKE_UNIQUE
    std::unique_ptr<Foo> l_ptr = std::make_unique<Foo>();   
#else
    std::unique_ptr<Foo> l_ptr;
    l_ptr.reset(new Foo());
#endif
}
catch(...)
{

}

AddressSanitizer does not report any issue as well.

(P.S. this was a nice opportunity to show off the less known function-try-block language feature.)

---

"Why doesn't the memory get leaked?"

The standard guarantees that the memory allocated with a "new expression" will be automatically freed if an exception is thrown during construction.

From $15.2.5:

If the object was allocated by a new-expression ([expr.new]), the matching deallocation function ([basic.stc.dynamic.deallocation]), if any, is called to free the storage occupied by the object.

---

Related questions:

• "What happens to the memory allocated by new if the constructor throws?"

• "std::unique_ptr::reset and constructor exceptions"

• "Is it ever not safe to throw an exception in a constructor?"