This doesn't answer my point. Namely, that destroying the shared pointer should not "clean up"/"try to clean up"/"dispose" the referenced object, unless this is the last shared pointer to that object. -- Shared_pointer is a part of the object most of time or local variable which will be freed at the end of lexical scope. So only protect it as a field member of object will do, no need to worry about the lexical scope. And if memory is not messed-up, it��s already being protected �C this gets back to how you define destroying object. You already see this object as destroyed, then no further answer is valid for you. If you see it��s not destroyed, no question is needed to be asked. *** If you don��t see the code, whatever I say you can not understand for sure! --- This doesn't require a special syntax. You can have a regular function to clear the object, and have that function called from rcgc_shared_ptr. -- True, that��s why this is just the answer to Rob��s question and the reason for the following answers. -- I don't think "the universal smart pointer" is practically possible or even desirable. shared_ptr is close to that ideal, but obviously that kind of flexibility has an associated cost that not everyone is willing to pay. This is why there are other kinds of smart pointers, some of which overlap with shared_ptr in functionality. -- Why just don��t read the code? I can not force you. But if we talk about something, we have to Base on something, not thinking or imagination or desire, Aren��t we? -- And even if we do want to implement a universal smart pointer, it still doesn't explain the need for a new special function. -- So just don��t. -- If you're not intending to change the language then both changing the destructor special semantics and the new syntax for dispose function are moot. (To be clear, I don't like either of these ideas.) -- Then ignore this as never happened (told you that it��s the reply to Rob) -- That's not how C++ standardization works, as what went into the standard is there to stay for many years ahead. You don't put stuff in the standard just to test the idea. But since you're not planning to propose a change in the language, you are mostly limited to a library-only solution. Which means, your code has to play by the current C++ language rules. -- Dispose pattern does not violate anything. -- I did not run the code, as I can see how it works without running it. I don't see it solving any of the problems with shared_ptr, and I have pointed out problems with the code, which you seem to have disregarded so far. -- The problem is the detor��s abusing, I accepted and provided solution which means not disregarded at all. However the abusing is not even the part of the idea or algorithm: just to make it beautiful in C++. Changing back to common function is OK. And do you want me to rewrite this to the C++��s standard? Don��t you think it��s going a bit far as a conversation? Is that so necessary?