From: ÒÝÁØ Ñî (yyl_20050115_at_[hidden])
Date: 2020-07-31 21:02:19
As far as I can tell, rcgc_shared_ptr<T> calls the destructor of T as soon
as its destructor is invoked, regardless of whether other references exist.
rcgc_shared_ptr<X> p1( new X );
rcgc_shared_ptr<X> p2( p1 );
} // ~X is called here
// *p1 references a destroyed object here
This doesn't seem correct to me; the point of shared_ptr is to not call the
destructor of the pointee as long as references (such as p1 in the code
above) exist to it.
Yes, you¡¯re correct. The detor of rcgc_shared_ptr<X> calls the X¡¯s detor
As soon as rcgc_shared_ptr<X>¡¯ object p2 leaves its scope. However
P1 still holds the object. So only p2¡¯s ~X() is called, not p1¡¯s ~X().
If both called, the same object (new X()) will be free.
Although calling dtors, but it does not mean certainly, free or mess-up the object generated by new X().
Only when the reference count decreased to zero, the object generated by new X() will be free.
(Here I discussed with Andrey and Janson about if it¡¯s valid to use
the data which is called detor upon)
So this is not the behavior you expected as shared_ptr you know.
If you write X like this
It can be a disaster as text object would be freed twice or more while the detor of X called maybe twice or more.
but if you write X like this
And use the text field accordingly,
It will be good and correct, because rcgc_shared_ptr already managed the memory for you (including the situations that the detors of std::string
Maybe called multiple times)
I admit that I didn¡¯t follow the semantics of the orginal shared_ptr. Maybe another name, just rcgc_ptr is better.
It¡¯s just smart pointer for you to manage memory allocations and deallocations. Maybe on the level of object creation/destructions is incorrect
(with other way of managing pointers or objects), but rcgc_shared_ptr still cares it for you.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk