On Tue, Mar 10, 2020 at 12:42 AM Jens Gustedt via Liaison <
liaison_at_[hidden]> wrote:

> J,
>
> on Tue, 10 Mar 2020 00:21:52 -0700 you (J Decker via Liaison
> <liaison_at_[hidden]>) wrote:
>
> > I might again stress, in a different way, it's about the member in the
> > object, not the whole object.
>
> That is the intent, yes, but not the effect.
>
> (*p).member
>
> has `*p` in it, which is an "evaluation" of the object as a whole. In
> a non-optimized compilation, this may trigger the load of
> uninitialized pointer members, for example.
>
> In the Memory Model SG we are trying to put our hands on this kind of
> stuff, and for the moment there are as many opinions as are people
> involved how and when the effective type rule ensures that such a
> pointed-to object acquires the type. Doing it with → is easy, doing it
> with (*). is a headache.
>

'doing it with (*). is a headache.' So you're saying the working in the
C++ standard makes it difficult?
and that actually treating E1.E2 as (&E1)->E2 makes it easy?

In the meta generation (as applied from gcc/parser.c) into whatever it
generates... the appearance of E1->E2 and the new phrase E1.E2
 generates exactly the same results.
Whereas if E1 is a structure, not a pointer, then E1.E2 returns (&E1)->E2
as one would expect.





>
> Thanks
> Jens
>
> --
> :: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
> :: ::::::::::::::: office Strasbourg : +33 368854536 ::
> :: :::::::::::::::::::::: gsm France : +33 651400183 ::
> :: ::::::::::::::: gsm international : +49 15737185122 ::
> :: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2020/03/0063.php
>