Missed optimization with const member

[Martin Sebor]

On 07/07/2017 06:26 AM, Ion Gaztañaga wrote:
> On 05/07/2017 17:24, Martin Sebor wrote:
>
>> [*] While the example (copied below) is valid, accessing the object
>> after someFunction() has returned via a reference or pointer to it
>> is not.
>>
>>    void somefunction(const Object& object);
>>    {
>>      void* p = &object;
>>      object.~Object();
>>      new(p) Object();
>>    }
>
> I think it's problematic as explained in p0532r0.pdf. We construct and
> destroy objects in the internal buffer of std::vector and we don't
> update the pointer every time. I don't see myself understanding when
> std::launder must be used, looks too expert-grade feature.

The problem with vector is new in C++ 17 and caused by lifting
the assignability requirement without fully considering the
ramifications.

But there are a number of intertwined problems here and this
is just one of them.   The text that makes references and
pointers invalid was added in C++ 03 to fix one problem (CWG
issue #89).  Launder tries to patch over a problem caused by
introducing optional in C++ 14, again without considering CWG
89.  As a result of its narrow focus (as Niko's paper points
out) it doesn't fix other manifestations of it.  CWG issue
#2182 describes a related defect in arithmetic involving
pointers to individual objects constructed at consecutive
locations in the same block of memory that launder doesn't
do anything for. As Niko's paper also highlights, launder
isn't a complete or, IMO, even a very good solution to
the problems.  It adds even more complexity without solving
all the underlying problems.  Adding more, complex features
that even experts have trouble understanding is what caused
these problems to begin with.

Martin