On 2020-08-03 18:41, 逸霖 杨 via Boost wrote:
1. Calling dispose method when the rcgc_shared_ptr is destroyed is still wrong. By definition, there are supposed to be multiple pointers to a shared object, and destroying a single shared pointer must not result in "cleaning up" the shared object. -- So disposing here is not meaning “cleaning up“ but “trying to clean up”(it’s better to have another word to call it), !A() serves as ~A() the difference is it just call the disposing methods of the field’s members’ rcgc_shared_ptrs to decrease reference counts. Actually they can be almost same (!A() and ~A()) in generated assembly or machine code. Only difference is !A() only calls about the rcgc_shared_ptr, and ~A() calls about all the dtors of field members. Yes, this is upon the assumption that the memory of that object is not touched or messed up (since not ~A(), just !A(), then it should not be touched by design).
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.
2. What is the purpose of the special syntax of the dispose function? What is its semantics outside the rcgc_shared_ptr? Why do you need this special syntax and not a regular method that is used by rcgc_shared_ptr? These are the sort of questions you will be asked by the committee when you bring this proposal. In fact, I think you'll me asked these even before you bring the proposal before the committee. There needs to be a very strong reason to introduce a new syntax.
-- The purpose is only to answer Rob’s reply: if trying to make things look beautiful without changing the original design of C++ language, the only choice is to add some extra syntax.
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.
Yes, this needs a very strong reason. So what do you think, if reference counting algorithm can be tuned up into “universal” mode and achieve the goal that the smart pointers are designed to achieve? (the one and only smart pointer to manage memories without coders’ attention)
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. And even if we do want to implement a universal smart pointer, it still doesn't explain the need for a new special function.
The reply to Rob was not cc to the list and this reply is following that one. I already said in that one, it’s not my purpose to bring a proposal to the committee.
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.)
Reason: things evolve, and the good ones continue and being accepted, and the users are the judges, so let the users judge. If good enough, got accepted; not good enough, got forgotten.
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.
I think or hope you already read and debug the code and already be aware of how it works. This understanding of the code is the basic ground we talk about further.
Because the code answered the reason already. (We’re coders, aren’t we? The code speaks better then my vocabulary-limited English.)
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.