On Thu, 19 Jan 2023 at 09:29, Frank B. Brokken via Std-Discussion <std-discussion@lists.isocpp.org> 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

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

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