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