P0137R0 "Core Issue 1776: Replacement of class objects containing reference=
 members"
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0137r0.html

This is continuation of the previous thread
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/gN-_7CJ58G4/di=
scussion
which raised questions on N4430 which is the previous version of P0137R0.

The same request about the contents of the paper still applies to the
revised one.
> ... But I believe decisions from such discussions and their
> rationales will be recorded in public papers.
>
> The current version (N4430) seems too quiet on that. I expect revised
> one will include answers to given questions and possibly some more which
> were already solved by yourself or in the committee.

I have tried to read minutes of discussion made at Kona about the paper
written in the following page in French, with Google translate service.
http://h-deb.clg.qc.ca/Sujets/Orthogonal/wg21-2015-Kona.html

But I still can't figure out answers for some of questions raised in the
previous thread. So I retry with summarized questions.


1.
Where std::launder() is expected to be written?

Is it written in library function (operator* of optional, operator[] of
vector, ...) or user code which use such functions with concerned types?

This is the last question I made in the previous thread.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/qYBl=
vIv2DgAJ

2.
What wording in the current standard (C++14) invalidates accesses
through a result of conversion (reinterpret_cast) between pointer of an
object and pointer to its first subobject?

There is addition of Notes in the proposal:
> [ Note: Nonetheless, if a pointer to the object is cast to a pointer to
> the type of its first subobject (or vice versa), the resulting pointer
> does not point to the subobject and cannot be used to access it.
> =E2=80=94end note ]
You claimed in the previous thread that "... it was observed that an
existing C++ optimizer was already optimizing on the basis of such casts
being invalid, based on a (reasonable) reading of the current wording of
the standard." as the reason of banning such accesses.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/4JG3=
i4S25z8J

I still can't find any such wording. While I know wording in 3.9.2
[basic.compound] p3 (which is deleted in the proposal) that can be read
to allowing such accesses.
> ... If an object of type T is located at an address A, a pointer of type
> cv T* whose value is the address A is said to point to that object,
> regardless of how the value was obtained. ...

That seems making incompatible changes to get some optimization
opportunity. Can it be well justified?


3.
It is possible (or not) to plug the effect of std::launder() to some use
of built-in cast operators and union member access which are expected to
be already written in lifetime manipulations like optional<T> do?

That will reduce some chance of optimization, but sounds safer
direction. It will encouraging people to avoid such casts or union
member accesses for efficiency, which sounds good direction, too.

This is the same question I made in the previous thread.
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/gN-_7CJ58G4/7NWb=
eT1yFmcJ

--=20
k_satoda

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

.