Re: [lmi] Reference member = shared_ptr

[Vadim Zeitlin]

On Tue, 2 Feb 2021 14:48:49 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

[...snip all the explanations as I have nothing to add...]

GC> I think everything is reasonable now, as just pushed.

 I agree, this makes much more sense if the cache is mutable (which is
something I also had completely forgotten about, sorry). But, just for
completeness, I'd like to add that it still could be achieved without
shared pointers: you're right in that using unique_ptr<> wouldn't work if
its internal pointer changed during the program lifetime, but the simple
solution is to just not use pointers at all and use objects in the first
place. Then instead of allocating a new object and assigning it to the
unique_ptr<> we would just assign the new values to the existing object.
As long as we keep using the same object from the beginning until the end,
there is no danger of ending up with a dangling pointer to it.

 I admit, I don't know if it's worth making such a change, but I'm just
very suspicious of widespread shared pointers use. This is something it
took me a long time to understand, but I'm about as unenthusiastic about
shared pointers since, maybe, 2015, as I was enthusiastic about them back
in 2005, because in the intervening years I kept running into deep and
complicated problems and bugs due to the implicit and very hard to find,
let alone fix, reuse of the same object from completely different program
locations via shared pointers to it. Of course, this doesn't happen in
simple examples and it almost surely isn't going to happen here and, also,
using shared_ptr<T const> is much better than using shared_ptr<T>. But,
still, I've earned healthy (or at least I hope that it is) distrust of
shared pointers after using them heavily in many projects and now always
try to avoid them unless it's really necessary -- and the surprising thing
is how rarely it actually is, especially in single-threaded code.

 Regards,
VZ

pgp0y85RdPgsQ.pgp
Description: PGP signature