Re: [lmi] Reference member = shared_ptr

[Vadim Zeitlin]

On Sat, 6 Feb 2021 14:14:21 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

GC> On 2/6/21 1:39 PM, Vadim Zeitlin wrote:
[...]
GC> >  BTW, the only tiny comment I had when reading these commits was about
GC> > make_unique(): it also has another minor advantage, which is to avoid 
using
GC> > "raw" new, which is nice too.
GC> 
GC> Before adopting a principle to favor make_{shared,unique}, I wanted
GC> to understand the rationale.

 I think you already understand it perfectly fine, there is really just not
much to it (which also explains why make_unique wasn't even added in C++11
and had to wait until C++14, i.e. clearly the standard committee didn't
consider it very important neither).

GC> make_shared formerly had an exception-safety rationale, but
GC> C++17 rendered that argument moot

 Yes, and IME this had been moot in practice even before, i.e. I had never
seen this problem actually happen, neither with make_shared nor with
make_unique. But it's, of course, still good that C++17 now guarantees that
it can't happen.

GC> The only really compelling reason I found was that make_shared does a
GC> single memory allocation instead of two (one for the object, and one
GC> for the data), one being presumptively better than two for cache
GC> locality (I can't demonstrate it, but I accept it on faith).

 Yes, so do I. I.e. it's like with pre- vs post-increment in the loops,
except I think the effect could be much more noticeable here, especially if
you have a vector with many shared pointers in it (which is a rather common
case). But mostly it's very clear that if an extra heap allocation can be
avoided, it should be avoided because we know that those things don't come
for free, even if their cost is not that big, and so not using make_shared
is just an intentional pessimization for no good reason.

GC> As for avoiding "raw" new: okay, sure, I don't disagree. I had
GC> already pretty much adopted a principle that 'new' is to be avoided
GC> except when its result is used immediately to initialize a smart
GC> pointer. Using make_{shared,unique} is now the tidiest way to
GC> honor that principle, and has the advantage that 'new' need never
GC> be written. Perhaps next I'll replace every occurrence of 'new'
GC> (excepting "new(wx)"), because grepping for /new/ is frustrating
GC> and it'd be good to get this done once and for all.

 Yes, exactly. The advantage of make_unique is that now you don't have to
review the code manually to check if this particular occurrence of new is
fine because it's immediately assigned to a smart pointer or not, but can
just grep for it. In fact, you could even set up a code check rule
verifying that there are no raw news other than new(wx) if you wanted to
(this is probably not really useful for lmi because you wouldn't check such
code in anyhow, but it can be pretty useful for projects with higher number
of contributors).

 Regards,
VZ

pgpL6dCUtBJkp.pgp
Description: PGP signature