About void Dispose() { if (this->_ptr != nullptr) { PTR* _ptr = this->_ptr; this->_ptr = nullptr; _ptr->~PTR(); RelRef(_ptr); } } Especially _ptr->~PTR(); This is not delete _ptr; Because: delete _ptr = _ptr->~PTR() + free(_ptr) We use _ptr->~PTR() to give shared_ptrs to decrease count and all descendent objects to decrease count, but not free any of them And then check if anything to be free at the end of destructor of shared_ptr。 if anything including self to be free, we free them all together then. ~rcgc_shared_ptr() { this->Dispose(); if (_ac) { Collect(); } } If _ac (auto collect) is true, we do collect here. void rcgc_base::Collect(std::vector<void*>& p_wilds) { if (p_wilds.size() > 0) { for (auto p = p_wilds.begin(); p != p_wilds.end(); ++p) { if (*p) { //delete p->first; //NOTICE: use free instead of delete to avoid double calling destructor free(*p); } } p_wilds.clear(); } } So we have options now: either collect at the end of destructor of shared_ptr, and collect everything with rc of 0; or we collect everything when we need to collect or in other dedicated thread (that’s the advantage). BR, Yilin 发送自 Windows 10 版邮件<https://go.microsoft.com/fwlink/?LinkId=550986>应用 发件人: Andrey Semashev via Boost<mailto:boost@lists.boost.org> 发送时间: 2020年7月31日 17:51 收件人: boost@lists.boost.org<mailto:boost@lists.boost.org> 抄送: Andrey Semashev<mailto:andrey.semashev@gmail.com> 主题: Re: [boost] Hello everybody, I have something to share about the shared_ptr class On 2020-07-31 11:52, 逸霖 杨 via Boost wrote:
Hello dear boost members,
I’m quite honored to join this mail list for the first time!
As I was told that the boost project is where the shared_ptr class originated, so I think it should be OK to talk about it here.
Here I have some ideas and code on my version of shared_ptr class.
The aim is to remove the usage of weak_ptr and fix the circular reference problem.
Please check code on https://github.com/yyl-20020115/RCGC
That’s the idea and primitive implementation. I don’t know exactly how to test it more widely among situations, please help me to find the very situations that this solution would fail, and I’ll try to fix it ASAP.
READM.md is a good start and README_ZHCN.md is better if you can read Chinese. However, I don’t think I can illustrate the algorithm very well both in English and Chinese. Well the code speaks for itself, and please read the code and run the program.
Please generate a makefile and build with CMakeLists.txt on *nix platforms if Visual Studio 2019 (where I code the project) is not available.
All ideas and discussions and help from you are all very welcome!
So, it looks like you're just doing garbage collection in a separate thread instead of freeing memory on the last reference counter decrement. Which means that your claim that memory consumption is the same as the original shared_ptr is not quite true. IMHO, GC is a too costly and unpredictable solution. I don't see myself ever wanting to have a GC, unless in a *very* localized and controlled context, like a single function cleaning up after itself. Regarding how circular dependencies are resolved, I don't quite see the solution. In the rcgc_shared_ptr::Dispose method, you immediately destroy the referenced object, not even when the reference count drops to zero, which is plain wrong because other pointers may still refer to the object. If you didn't destroy it, in the circular dependencies case the reference count would never drop to zero, which means the GC thread would never collect the object. Lastly, I question the usefulness of a shared_ptr without a weak_ptr. Note that weak_ptr is not limited to just circular references resolution, it has other use cases. Although shared_ptr has other useful features, like pointer aliasing and deleter erasure, I find myself using shared_ptr almost exclusively when I also need weak_ptr. When I don't need weak_ptr I would use intrusive_ptr. But then your rcgc_shared_ptr doesn't provide any of the additional features of shared_ptr, so there's even less reason to use it. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost