From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2020-08-03 16:49:26
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk