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

From: Rob Stewart (rstewart_at_[hidden])
Date: 2020-08-01 23:08:29

On July 31, 2020 2:21:50 PM EDT, "逸霖 杨 via Boost" <boost_at_[hidden]> wrote:
> Hi Janson and Andrey,
> 
> I got your point. And I think you got mine too.
> 
> So this is so-called by-design.
> 
> Is this a good reason for rejecting an innovation?

It is absolutely a good reason. What you're doing is invalid C++, as Andrey and others have tried, repeatedly, to tell you. When you violate the rules of the language, your "innovation" is simply bad design.

> I’m not sure. I don’t make the definition of C++.
> Also, I’m here to contribute, not to dominate.
> 
> The answers implied that calling the dtors will end the object life
> once for all.
> But is there any explicit “once for all”.

Yes. By definition of the language, there is no object until a constructor runs, and objects cease to exist when their destructor begins.

The moment you invoke an object's destructor, no further access to its memory, other than its reclamation or reuse for another object, is undefined behavior. No design assuming the bits remain unchanged is valid. There's simply no other way to see this.

> Upon the definition of dtors, people made code, and the new
> understanding of dtors
> would result in unstableness, which I’m quite aware of.
> 
> However, what if someone who would like to keep a simple and neat
> usage of the dtors
> to help rcgc_shared_ptr to work in the best performance just in his
> own code? For example,
> my code, or his or hers?

People are free to write code relying on undefined behavior, but such cannot be generalized and would never be accepted into Boost. (There have been a few implementation details of Boost libraries that rely on undefined behavior, but those are conditionally compiled for specific compilers which define the behavior -- thereby going beyond the C++ Standard.)

Any library that depends upon users carefully designing all of their classes to avoid the bad effects of undefined behavior in the library, is unlikely to see much use.

> So, would anyone be kindly to help me to understand why we can not
> improve it together?

I hope you understand now.

(BTW, don't overquote -- retain no more of the previous messages than necessary.)
--
Rob
(Sent from my portable computation device.)