On Monday, 27 November 2017 at 15:56:09 UTC, Ola Fosheim Grostad
wrote:
On Monday, 27 November 2017 at 14:35:03 UTC, Dmitry Olshansky
wrote:
Then watch Herb’s Sutter recent talk “Leak freedom by
default”. Now THAT guy must be out of his mind :)
He could be, I havent seen it... Shared_ptr isnt frequently
used, it is a last resort,
Ahhhaaahhha.
Really, shared_ptr is the most contagious primitive of modern C++.
To quote MS STL guy “I’m surprised we had no non-inteusive
ref-counted ptr in std lib for so long”.
Going Native videos are full of questions on that.
atomic_shared_pointer is nothing but what you seem to imply.
It’s not manual sync for one.
Err... That was my point... Only assignment and reset is
protected in shared_ptr, all other methods require manual sync.
For the benefit of others, let me destroy that:
- shared_ptr allows to share T with thread-safe ownership,
ref-counts are accounted atomically (sharing copies of shared_ptr
pointing to the same block). Copy of shared_ptr is thread safe
and does the count.
- atomic_shared_prt would also allow one to initialize a shared
variable (eg global) of type shared_ptr safely from multiple
threads
The manual synchronization part comes in if you try to work with
payload T itself. THAT is manual.
Since C++ doesn’t see a difference at type level of shared vs
local, there is no thread-local variation of shared_ptr. It would
be too unsafe even for those guys, contrary to what Ola responses
imply.
You keep spreading FUD on this forum, I’m still not sure of
your reasons though.
And there we go ad hominem as usual... With no argument to back
it up... Bye.
Well I can clearly see misinformation and describe it as such.
See your point about atomic_shared_ptr.
