Date: Sat, 26 Feb 2022 04:28:02 +0400
Here's an abbreviated version illustrating the behavior: https://godbolt.org/z/63G5v63h3The output is:ctordtorException: boomThe ctor/dtor are for "f1", and there is no ctor/dtor for the other "f2".Which means the destructor does know from where to start destroying, right?It destroyed only successfully constructed member objects, right?But isn't the object's destructor when called, starts systematically destroying blindly from the last to first member object?After all it is meant to destroy a fully constructed object, right?So how did it know, that there is no need to destroy "f2"?Did you get my points?Sent from my Galaxy
-------- Original message --------From: Arvid Norberg <arvid.norberg_at_[hidden]> Date: 2/26/22 3:30 AM (GMT+04:00) To: std-proposals_at_[hidden] Cc: organicoman <organicoman_at_[hidden]> Subject: Re: [std-proposals] Relax condition for potentially invoked destructor in constructor On Fri, Feb 25, 2022 at 11:36 PM organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:Connor, ArvindAn object at construction does not call its destructor, in case of exception or error.A destructor exists only if the instantiated object had successfully been constructed. Look at this example: (pay attention to the member "TheFree d" of the class "test")[...]Please run your examples through compiler explorer, or something similar, before posting.The main mistake in your example is that division by zero does not throw an exception. It's undefined behavior.If you had bothered to include a return statement in your Throw() function, your compiler would have told you.When fixing your code to actually throw an exception, it works as one would expect.Here's an abbreviated version illustrating the behavior: https://godbolt.org/z/63G5v63h3You see Arvind? We are already paying the price of keeping record of constructed member objects. No.
There's no need for record keeping since the order of construction is
known at compile time, statically. It's encoded in the machine code, not
in any run-time data structure.So, you don't pay for it
(obviously there's the caveat that you pay some price for exception
handling, but I don't think that's what we're talking about).-- Arvid Norberg
-------- Original message --------From: Arvid Norberg <arvid.norberg_at_[hidden]> Date: 2/26/22 3:30 AM (GMT+04:00) To: std-proposals_at_[hidden] Cc: organicoman <organicoman_at_[hidden]> Subject: Re: [std-proposals] Relax condition for potentially invoked destructor in constructor On Fri, Feb 25, 2022 at 11:36 PM organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:Connor, ArvindAn object at construction does not call its destructor, in case of exception or error.A destructor exists only if the instantiated object had successfully been constructed. Look at this example: (pay attention to the member "TheFree d" of the class "test")[...]Please run your examples through compiler explorer, or something similar, before posting.The main mistake in your example is that division by zero does not throw an exception. It's undefined behavior.If you had bothered to include a return statement in your Throw() function, your compiler would have told you.When fixing your code to actually throw an exception, it works as one would expect.Here's an abbreviated version illustrating the behavior: https://godbolt.org/z/63G5v63h3You see Arvind? We are already paying the price of keeping record of constructed member objects. No.
There's no need for record keeping since the order of construction is
known at compile time, statically. It's encoded in the machine code, not
in any run-time data structure.So, you don't pay for it
(obviously there's the caveat that you pay some price for exception
handling, but I don't think that's what we're talking about).-- Arvid Norberg
Received on 2022-02-26 00:28:12