From: ÒÝÁØ Ñî (yyl_20050115_at_[hidden])
Date: 2020-08-03 17:24:55
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,
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
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk