Re: [lmi] Reference member = shared_ptr

[Greg Chicares]

On 2/6/21 1:39 PM, Vadim Zeitlin wrote:
> On Sat, 6 Feb 2021 00:03:54 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 2/5/21 5:01 PM, Greg Chicares wrote:
[...]
> GC> Done: new branch odd/unique_vs_shared2 . Would you recommend
> GC> merging that into master?
> 
>  Yes, I think it should be merged. It's not a huge gain, of course, but it
> is an improvement from the code clarity point of view IMNSHO.

Cherry-picked and pushed. Thanks.

>  BTW, the only tiny comment I had when reading these commits was about
> make_unique(): it also has another minor advantage, which is to avoid using
> "raw" new, which is nice too.

Before adopting a principle to favor make_{shared,unique}, I wanted
to understand the rationale. Reviewing online discussions, I saw
that make_shared formerly had an exception-safety rationale, but
C++17 rendered that argument moot. The only really compelling
reason I found was that make_shared does a single memory allocation
instead of two (one for the object, and one for the data), one being
presumptively better than two for cache locality (I can't demonstrate
it, but I accept it on faith). The other reasons seem squishy by
comparison.

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