Re: Hello everybody, I have something to share about the shared_ptr class

From: ÒÝÁØ Ñî (yyl_20050115_at_[hidden])
Date: 2020-08-03 15:41:20

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).

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.

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)

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.

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.

So this would not be a problem.

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.)