C++ Logo


Advanced search

Re: [std-proposals] Relax condition for potentially invoked destructor in constructor

From: organicoman <organicoman_at_[hidden]>
Date: Sat, 26 Feb 2022 21:05:03 +0400
Sorry guys i cannot explain more than what i did already."Destruction of an object in construction time is a totally different mechanism than destroying it after it finishes construction."We need a complier implementer to tell you why they chosen this lazy implementation, without blocking the user from the possibility of shuffling the order of initialization.End of thread.Just a side observation:I see a trend of people turning into standardees book worms, instead of using simple good sense and logic.FYI, standards are written by humans, those guys rely on our different vue of the world to correct them, improve their work and push the development forward.If we stop thinking out of the box, and stick to the wording (standard said so, or standard said so..) we will not make C++ nor its community a dynamic language and environment.That's my conclusion, until Sy comes inNadirSent from my Galaxy
-------- Original message --------From: connor horman via Std-Proposals <std-proposals_at_[hidden]> Date: 2/26/22 7:58 PM (GMT+04:00) To: std-proposals_at_[hidden] Cc: connor horman <chorman64_at_[hidden]> Subject: Re: [std-proposals] Relax condition for potentially invoked destructor in constructor On Sat, 26 Feb 2022 at 10:54, connor horman <chorman64_at_[hidden]> wrote:On Sat, 26 Feb 2022 at 10:43, organicoman <organicoman_at_[hidden]> wrote:I see the problem now.There is a big misunderstanding of when an object destructor is invoked, and what is its relationship with the constructors.To be saved by heart:"A destructor can be called only when the object is successfully constructed"Exple:struct object{ type1 member1; type2 member2; type3 member3;};At construction time, if i construct "member1" then "member2" then "member3", or"member2", then "member1" then "member3",Or in any other permutation possible.When the constructor finishs, i will have:member1, member2, member3 and the instance that contains them, all in their correct places and initialized safe and sound. At destructor invocation time, the destructor finds all the member subobjects in their correct places and it starts destroying from whatever order the standard wants.Yes, the order is the opposite that the objects were constructed in because that's what the standard specifies. However, in order to do this, it must know the order in which they were constructed.See this line in the standard: http://eel.is/c++draft/class.dtor#14.sentence-3 Why? Because the destructor is only available when all the subobjects exist and are in their places.Does it need to know how the object was constructed? NOHow hard is this to understand?The only thing that matters to a destructor is that the object finished construction successfully.C++ defines that all objects, except for complete objects with dynamic storage duration (where subobjects with dynamic storage duration maintain this order relative to all other subobjects of the same complete object) with manually managed lifetimes (or when placement-new/pseudo-destructor expressions are involved, but same deal with those as with other manual lifetime management), are destroyed in the reverse order they are constructed. This allows, among other things, that one object can refer to another constructed earlier, and in its destructor use a pointer/reference to the object in a way that requires the latter to be within its lifetime. This is true even for member subobjects. The destructor of the class, in order to preserve this guarantee, therefore needs to know what the order of construction of base class and member subobjects was in order for it to destroy them in the reverse order of destruction.Sy Brand !!Where are you?Help!Sent from my Galaxy-------- Original message --------From: connor horman via Std-Proposals <std-proposals_at_[hidden]> Date: 2/26/22 7:00 PM (GMT+04:00) To: std-proposals_at_[hidden] Cc: connor horman <chorman64_at_[hidden]> Subject: Re: [std-proposals] Relax condition for potentially invoked destructor in constructor On Sat, 26 Feb 2022 at 07:05, Arvid Norberg via Std-Proposals <std-proposals_at_[hidden]> wrote:On Sat, Feb 26, 2022 at 9:28 AM organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:The current implementation which assumes that the member initialization list calls the member subobjects constructors in order of declaration, otherwise garbage is produced.This is disaster!It's not so much an assumption as a definition, in order to keep things simple and efficient. The "disaster" is quite easily averted by "-Wall -Werror". As I said earlier, all major compilers will tell you if your initializer list is in a different order than declaration order. Where is the difficulty to implement it the following way:1- At compile time, scan the constructor member initialization list.2- create a dependency graph.3- make sure that class subobjects are initialized first in their order of inheritance. 4- generate code for the constructor under compilation, which will call the member subobjects constructors in different order than their declaration order in the class, as per the user wish.Isn't more intuitive?You keep hand-waving away the problem of the destructor possibly being defined in a separate translation unit that cannot see the definition of the constructor. You also hand-wave away the possibility of having two constructors that end up with different initialization orders. In that case you need to record, at run-time, which constructor was used for a specific instance, so the destructor knows which order to destroy its subobjects in. Doing either is a net negative in my book.Indeed. An easy case would have an inline (probably defined as default) destructor, and a non-trivial out-of-line constructor? What order does the defaulted destructor use to destroy the elements? Does it different between translation units (ODR)? Is it the same (potentially no longer reverse order of construction)? A combination of both is most likely under the above proposal, so you've not only broken the guarantee of Reverse-order of construction always, but you've also made the program IFNDR. In order for the proposal to actually be functionally viable it requires that the definition of every constructor be available in the translation unit that defines the out-of-line destructor or in every translation unit that contains the definition of the inline destructor, *and* every constructor must use the same initialization order. And what about default-initialized fields/fields with default-member-initializers? What order do they get initialized in? What happens with some constructors use explicit initializers for them, and others don't? The rule seems simple in theory, but in C++ it's far too complex, makes far too many trade-offs, and arguably comes with non-zero cost. You could invent a build system that guarantees that all translation units containing constructors are compiled first, then communicate which order they ended up deciding to initialize subobjects in, and then feed this information into all the translation units that contain destructors. I hope you see the difficulty and complexity of trying to do that (for virtually zero benefit).As a program writer, i will be free to not watch in which order i initialize my member objects, when writing my constructor. It is so flexible and saves the day.Passing "-Wall -Werror" to your compiler also saves the day, and is simpler. An object constructor is sensible piece of code, making it non-intuitive could lead to disaster. Just imagine this scenario:" some developer want to write the constructor of a defibrillator, then by mistake he didn't respect the order of initialization of just one member object, now his defibrillator instead of starting at ZERO volts power, it starts at a random value. Two consequences, either his code damages the machine, or kills the patient"That's why you would be required (by law most likely) to pass "-Wall -Werror" to your compiler when building medical devices.-- Arvid Norberg
Std-Proposals mailing list

Received on 2022-02-26 17:05:09