On Wed, Jan 18, 2023 at 12:38 PM Edward Catmur via Std-Discussion <
std-discussion_at_[hidden]> wrote:

> On Wed, 18 Jan 2023 at 17:18, Frank B. Brokken via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> Dear Edward Catmur, you wrote:
>> > On Wed, 18 Jan 2023 at 16:02, Frank B. Brokken via Std-Discussion <
>>
>> > > ... reaches the constructor's function-try-block handler.
>> >
>> > This seems to me a simple corollary of [class.cdtor], particularly
>> > paragraph 1. I'd even question whether normative wording is necessary
>> under
>> > [except.handle]; this could probably be a note.
>>
>> Hi Edward,
>>
>> Thanks for the fast reply to my question.
>>
>> 11.9.5 [class.cdtor] states:
>>
>> ... For an object with a non-trivial destructor, referring to any
>> non-static member or base class of the object after the destructor
>> finishes execution results in undefined behavior.
>>
>> However, that's not the situation I'm encountering. In the example an
>> exception is thrown from the constructor's body and so no destructor is
>> called.
>
>
> Ah, true; the destructor of the class is only called in case of a
> delegating constructor [except.ctor].
>
> So either the class is not "under construction or destruction" and
> [basic.life]p6 applies (and is thus inconsistent with [except.ctor]), or
> [class.cdtor] is incomplete, or possibly both. This might be a defect.
>

First of all, I'm sorry I didn't notice your first reply to this thread
before I wrote my reply.

Anyway, after having looked at [basic.life]/6, I don't see what the issue
is. I think that [basic.life]/6 does not give license to do all the things
that aren't specifically forbidden therein. If the class has a non-trivial
constructor, then the restrictions in [class.cdtor]/1 apply in addition to
the ones in [basic.life]/6.


>
> But before the exception is thrown its d_value has received a value,
>> which is then displayed in its function-try-block.
>>
>
> Well, yes, but you aren't allowed to access that value, both because that
> int object is outside its lifetime, and also because you aren't allowed to
> refer to the int object to access its value.
>
> >
>> > > But why would referring to members of basic data types like 'int' be
>> > > undefined?
>> >
>> >
>> > If the data member is a member of a virtual base class, the vtable
>> > (speaking concretely) and the offsets it contains necessary to compute
>> the
>> > address of that member may no longer be valid.
>>
>> True, but that's also not the situation encountered in my example.
>>
>
> This is a justification for the general rule. The Standard has cases where
> a rule is more general than absolutely necessary for the sake of simplicity.
>
> > There is an issue that [class.cdtor] is actually more restrictive here
>> than
>> > [basic.life], meaning that operations that are allowed on an object
>> fully
>> > outside its lifetime (principally, referring to a non-virtual base
>> class)
>> > can no longer be performed once it is under construction or destruction.
>>
>> But that, too, is not the situation in my Int class: there's no base class
>> either. It's just the plain Int class having a single int data member. So
>> I'm
>> still struggling with the question why referring to its d_value data
>> member
>> in the constructor's function-try-block implies undefined behavior
>
>
> Your d_value might be a member via a virtual base class of Int. It isn't,
> but it might be.
>
> > I'm not sure if we've got around to opening a CWG issue there.
>>
>> Well, maybe I posted my question to the wrong list, but since
>> https://isocpp.org/about/contact specifies that questions about the
>> standard
>> should be posted to this list, and since my question is about an item in
>> the
>> C++ standard and not so much about C++ itself I posted the question here.
>> I
>> tried several compilers with my example, and so far all resulting programs
>> show the line 'value = 5'.
>
>
> Well, that doesn't matter that much; there's lots of UB that isn't
> detected by any compiler. Although it does weigh towards suggesting that it
> might be worth considering relaxing that UB.
>
> But please advise if I should address the question
>> to 'StackOverflow C++'
>>
>
> No, you're in the right place. You might get an answer on SO, but they do
> have a tendency to see the Standard as not to be questioned. Here is a bit
> more relaxed.
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>

-- 
*Brian Bi*