Precise GC state
Dmitry Olshansky
dmitry.olsh at gmail.com
Mon Nov 27 17:16:50 UTC 2017
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.
More information about the Digitalmars-d
mailing list