This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/68164] Destructor side effect unexpectedly elided


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68164

--- Comment #2 from W E Brown <webrown.cpp at gmail dot com> ---
(In reply to Casey Carter from comment #1)
> [basic.life]/5 says:
> 
> Before the lifetime of an object has started ... or, after the lifetime of
> an object has ended and before the storage which the object occupied is
> reused or released, any pointer that refers to the storage location where
> the object will be or was located may be used but only in limited ways. ...
> Indirection through such a pointer is permitted but the resulting lvalue may
> only be used in limited ways, as described below. The program has undefined
> behavior if:
> 
> (5.1) â ...
> 
> (5.2) â the pointer is used to access a non-static data member or call a
> non-static member function of the object, or
> 
> ...
> 
> This looks like straight-forward violation of 5.2 resulting in UB.

By this reasoning, no c'tor or d'tor would be allowed, in its body, to access
any of its non-static data members or call any of its non-static member
functions.  There must be more to it, and indeed IMO there is.

According to the second sentence of [class.cdtor]/3:

"To ... access the value of ... a direct non-static member of an object obj,
the construction of obj shall have started and its destruction shall not have
completed, otherwise ... accessing the member value ... results in undefined
behavior."

Moreover, according to the first sentence of the next paragraph
([class.cdtor]/4), "Member functions, including virtual functions, can be
called during construction or destruction" [cross-references elided].

I conclude that the access in the test program's d'tor does not qualify as
undefined behavior and is therefore permissible.

Accordingly, I recommend further analysis of the original report.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]