On Mon, Aug 19, 2019 at 4:20 PM language.lawyer--- via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> >> The creation of an object of type T would end the lifetime of the array
> >> elements, so accessing them would be UB.
> >>
> >
> > An array of unsigned char or std::byte can have an object of some other
> > type nested within it, so the array's lifetime is not ended.
>
> Right, but I wrote that the lifetimes of the array *elements* would end.
> There is no "nested within" relation between the elements and an object
> which is placed over them.
>

[intro.object]/3
If a complete object is created ([expr.new]
<http://eel.is/c++draft/expr.new>) in storage associated with another
object e of type “array of N unsigned char” or of type “array of N std::byte”
([cstddef.syn] <http://eel.is/c++draft/cstddef.syn>), that array *provides
storage* <http://eel.is/c++draft/basic.memobj#def:provides_storage> for the
created object if: ...

[intro.object]/4
An object a is *nested within*
<http://eel.is/c++draft/basic.memobj#def:nested_within> another object b if:
*...* or b provides storage for a, or ...


[basic.life]/1
The lifetime of an object o of type T ends when: ... the storage which the
object occupies is released, or is reused by an object that is not nested
within o ([intro.object] <http://eel.is/c++draft/basic.memobj#intro.object>)
. <http://eel.is/c++draft/basic.memobj#basic.life-1.sentence-4>


>
> >> This just shows that the access to object representations do not fit
> well
> >> into the current model of the C++ abstract machine.
> >>
> >
> > Indeed. On one hand, one could conclude that people who want to access
> > object representations should just suck it up. On the other hand, one
> could
> > observe that the current C++ memory and object model results in a lot of
> > pre-C++17 code being broken, and conclude that it should be revised.
> >
> > Besides, even if you think that no one should ever try to access object
> > representations of anything much more complicated than a struct with a
> > bunch of ints in it, do you think it is reasonable to limit typical usage
> > of offsetof to such types as well? If I have a pointer to a member of
> some
> > class that is standard-layout but not implicit-lifetime, should there not
> > be a way for me to get a pointer to the enclosing class using pointer
> > arithmetic? Are you comfortable with letting all the existing code of
> this
> > form, written before C++17, continue to be broken? What did we gain from
> > the C++17 changes that was so beneficial that it justified *silently
> > breaking* said code? What about the fact that the migration effort for
> such
> > code can be significant (given, as I've pointed out, the inadequacies of
> > the proposed std::bless solution)?
>
> Isn't offsetof usually used in some low-level code which typically also
> breaks the strict aliasing rule?
> There are compiler flags making the later behavior defined.
> It is not forbidden for implementations to define behavior which the
> standard does not define.
>

I don't see why that is necessarily the case. It could, for example, be
used to allow a user to remove an object from a node-based container given
a pointer to the object. There's no reason why such code should have to
depend on special flags to make strict aliasing violations well-defined.
Oh, sure, you can rewrite the container so that its API is based on
iterators instead, to avoid this problem---and, of course, you'll also have
to rewrite ALL the code that uses it. As I said, the migration effort is
"significant".


>
> >>>> I do not think that this is a good way.
> >>>>
> >>>
> >>> What problem did this cause when it was effectively the status quo in
> >>> C++14, that is so serious that we should not attempt to codify it in
> >> C++23
> >>> or some future version of the standard?
> >>
> >> I do not think calling bytes of memory "objects" is a good status quo.
> >>
> >
> > Is that really your only objection? Presumably, it would be possible to
> > word the changes to the standard in a way that would avoid this. The
> point
> > is that existing code relies on being able to do pointer arithmetic on
> > memory that various types of objects occupy *as though* an array of
> unsigned
> > char objects existed there. We don't have to say that there are actual
> > objects. Given the way pointers work in C++17, I think this would
> require a
> > lot of wording, but I think I've already stated enough times how the
> > alternative of doing nothing leaves a lot of code broken.
>
> I don't know the solution for this problem :/
>

I don't know the solution either, but I felt it was important to point out
how "just use std::bless" is not a solution.
It's good that we're at least talking about the OP's proposal (although I
can't access it right now... what happened to the github link?)


> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*