On Thu, 19 Jan 2023 at 09:29, Frank B. Brokken via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> Hi Edward, hi Brian,
>
> Edward, in your 18 Jan 2023 17:38:30 +0000 e-mail you wrote
>
> > Although it does weigh towards suggesting that it might be
> > worth considering relaxing that UB.
>
> Maybe, instead of nitpicking on minute elements of the C++ standard,
> something
> like the following relaxation of item #10, section 14.4 could be
> considered:
>
> 10 Referring to any non-static member,
> non-basic type data member,
> or base class of an object in the handler for a function-try-block
> of a
> constructor or destructor for that object results in undefined
> behavior.
>
> It's not a big issue, but it's always nice when it's clear why rules
> exist, and in the current version of #10 that doesn't seem to be completely
> true.


The current wording does two things:

- it bars calling member functions, especially including virtual member
functions
- it prevents forming references (formally, lvalues) to data members,
especially including data members of virtual base classes.

Hopefully you see why the latter half of each of those is necessary. (For
data members, consider diamond inheritance.)

It doesn't even *need* to prevent access to data members of scalar type,
since the lifetime of such has already ended so access is barred by
[basic.life]/4.

It's obvious that class type data members cannot be used in constructor
> function-try-block handlers, as their destructors have already been called
> by
> the time execution enters those handlers, but as basic-type data members
> don't
> have destructors they remain available for as long as the object's memory
> remains available (or am I missing something and are there some spooky
> things going on by the time the handlers begin their executions?).
>

There may be. Implementations have freedom to poison the memory to help
detect bugs, or to reuse it for their own purposes, and so on.

In any case, thanks a heap for replying to my postings. For now I'll make
> sure
> that my code obeys #10, but who knows, maybe the rule will/can be relaxed
> :-)
>
> Kind regards,
>
> --
> Frank B. Brokken
> (+31) 6 5353 2509
> PGP Key Fingerprint: DF32 13DE B156 7732 E65E 3B4D 7DB2 A8BE EAE4 D8AA
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>