From: Uwe Hermann <uwe@hermann-uwe.de>
Date: Fri, 10 Mar 2017 19:26:31 +0000 (+0100)
Subject: Prefer std::make_shared().
X-Git-Url: http://git.code-monkey.de/?a=commitdiff_plain;h=067bb62415847791709f4c3cad8bb252a63f45f8;hp=067bb62415847791709f4c3cad8bb252a63f45f8;p=pulseview.git

Prefer std::make_shared().

This patch was generated using clang-tidy:

  clang-tidy -checks="-*,modernize-make-shared" -fix

(with some additional manual fixups)

Using make_shared() over manual construction has multiple advantages:

 - It's shorter to write and easier to read.

   V1: auto sb = shared_ptr<Foo>(new Foo());
   V2: auto sb = make_shared<Foo>();

 - The type "Foo" is repeated less often (less code duplication, lower
   risk of forgetting to update one of the "Foo"s upon copy-paste etc.)

 - Manual construction leads to two individual allocations (actual data and
   the control block of the shared_ptr). Using make_shared() will only lead
   to one allocation, which has performance, cache-locality and memory
   consumption benefits.

 - It's exception-safe, whereas manual construction is not necessarily:

   V1: func(shared_ptr<Foo>(new Foo()), shared_ptr<Foo>(new Foo()));
   V2: func(make_shared<Foo>(), make_shared<Foo>());

   In "V1", one of the "new" invocations could throw, potentially
   causing memory leaks. No leaks will happen with make_shared().
---