On 30 May 2013 17:15, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:

>
>
>
> On 30 May 2013 16:57, Nikolay Ivchenkov <mk.ivchenkov_at_[hidden]> wrote:
>
>>
>> regardless of the definition of f (which may be unknown for compiler).
>> There is no legal way to modify reference x.ref after its initialization
>> so that it would refer to a different location. Even if we overwrite the
>> storage of x by construction of a new object of type X at address &x (our f
>> could do such thing), a compiler may assume that x.ref is untouched. The
>> same applies to the original example with optional.
>>
>>
> I see, thanks, that's a very good explanation. But there's still the
> difference that the 3.8/7 would seem to refer to
> the storage of A inside the optional (in the original example of yours),
> and we never had a pointer or a reference
> to that storage, but we have a reference inside that storage. Same with
> this latest example of yours, isn't
> explicit destruction and placement-new of x legal, and allowed to modify
> the reference inside the storage
> of x? If we had a pointer/reference to that storage previously, we
> wouldn't be able to refer to the new
> object via those, but in the example we do not have such a
> pointer/reference.
>

In other words, I wouldn't expect the compiler to be able to perform the
optimization you suggested,
if it doesn't see the definition of f(), since f may take a reference and
create a new object
into the storage of x. Should X have a user-provided copy constructor, that
copy constructor
could do the same thing even if f() takes its parameter by value.