Date: Wed, 19 Jun 2024 08:58:27 +0100
On Wed, Jun 5, 2024, I wrote wrote:
>>
>> Specifically the problem is as follows:
> > (1) If we destroy the string before calling the helper, then we
> > get a segfault
> > (2) If we don't destroy the string before calling the helper, then
> > we get a memory leak
> >
> > I don't think that No. 1 can be remedied at all -- we can't query an
> > object after its memory has been deallocated. But I think that No. 2
> > can be remedied if we relocate the object in order to destroy it later
> > at a different location. So the chain of events inside the 'emplace'
> > method would be:
> > (1) Relocate "*opt_str" to another memory address
> > (2) Invoke the helper function (thus overwriting the string in-place)
> > (3) Destroy the relocated string
In the above post, I wrote that No. 1 cannot be remedied at all. But
then I realised there's a circumstance in which it can be remedied: if
T is trivially destructible.
So I think PRvalue parameters would work fine so long as T is
trivially destructible.
>>
>> Specifically the problem is as follows:
> > (1) If we destroy the string before calling the helper, then we
> > get a segfault
> > (2) If we don't destroy the string before calling the helper, then
> > we get a memory leak
> >
> > I don't think that No. 1 can be remedied at all -- we can't query an
> > object after its memory has been deallocated. But I think that No. 2
> > can be remedied if we relocate the object in order to destroy it later
> > at a different location. So the chain of events inside the 'emplace'
> > method would be:
> > (1) Relocate "*opt_str" to another memory address
> > (2) Invoke the helper function (thus overwriting the string in-place)
> > (3) Destroy the relocated string
In the above post, I wrote that No. 1 cannot be remedied at all. But
then I realised there's a circumstance in which it can be remedied: if
T is trivially destructible.
So I think PRvalue parameters would work fine so long as T is
trivially destructible.
Received on 2024-06-19 07:58:38