On Thu, 10 Nov 2022 at 18:07, Andrey Erokhin via Std-Discussion <std-discussion@lists.isocpp.org> wrote:
>>>>>>> According to a non-normative note in
>>>>>> https://eel.is/c++draft/defns.access,
>>>>>>>
>>>>>>> "Only glvalues of scalar type can be used to access objects. ...
>>>>>> Attempts to read or modify an object of class type typically invoke a
>>>>>> constructor or assignment operator; such invocations do not themselves
>>>>>> constitute accesses, although they may involve accesses of scalar
>>>>>> subobjects."
>>>>>>>
>>>>>>> The question is, can objects of class type be accessed?
>>>>>>
>>>>>> Can, in some sense. But it would be UB. E.g.
>>>>>>
>>>>>> struct S
>>>>>> {
>>>>>>            char buf[sizeof(int)];
>>>>>> } s;
>>>>>>
>>>>>> reinterpret_cast<int&>(s) = 0; // kinda accesses `s`, but this
>> violates
>>>>>> strict aliasing, so the behavior is actually undefined
>>>>>>
>>>>>
>>>>> It accesses `s`'s storage, sure.
>>>>
>>>> What do you mean by explicitly writing «storage»? You disagree with that
>>>> the expression accesses `s`?
>>>>
>>>
>>> Yes, since `s` is not a glvalue of scalar type.
>>
>> But reinterpret_cast<int&>(s) is. And it denotes the `s` object. Per
>> [expr.ass]/2, the referred-to object is accessed.
>>
>
> Why does it denote `s`?

Hm. Because the standard says so.

In which section? Is this [expr.static.cast]/11?

> That looks to me like it ends the lifetime of `s`.

With undefined behavior, everything is vacuously true.

Sorry, I was thinking of [intro.object], but that only works with `new`.

>>> But a read would not have undefined behavior.
>>>>
>>>> [basic.lval]/11 apply uniformly to both kinds of access: reads and
>> writes.
>>>>
>>>
>>> Oh oops, didn't spot that the reinterpret_cast was to int. If it was to a
>>> storage-like type, that would be well-defined, no?
>>
>> No.
>>
>
> Why would [basic.types.general] not hold?

You mean [basic.types.general]/2? Don't think it would count as copying the object's underlying bytes to the array.

Again, my mistake; I was thinking of [basic.lval]/11.

And that resolves the whole discussion (well, via a Note):

> [...] C++ has no notion of accessing an object of class type through an lvalue of class type.