Prefer std::make_shared().
commit067bb62415847791709f4c3cad8bb252a63f45f8
authorUwe Hermann <uwe@hermann-uwe.de>
Fri, 10 Mar 2017 19:26:31 +0000 (10 20:26 +0100)
committerUwe Hermann <uwe@hermann-uwe.de>
Sat, 11 Mar 2017 12:06:03 +0000 (11 13:06 +0100)
tree940a9dd3270b1dda99a809372ab7c95ac6b34afb
parenteb8269e3b5eebdd77e6a82d42bcfdfbc3f7613a9
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().
pv/data/decoderstack.cpp
pv/popups/channels.cpp
pv/session.cpp
pv/view/decodetrace.cpp
pv/view/view.cpp