The resource will continue to be managed, but by a different object; the lvalue object materialized from the prvalue relocated from the original owner lvalue. So it will be released when the new object's destructor is called.It sounds like a garbage collection mechanism. Can you please illustrate with an example how we keep track of the resources from the first object which was relocated-from (let's name it the 'relocation source')?Sent from my Galaxy
-------- Original message --------From: Edward Catmur <ecatmur_at_[hidden]> Date: 5/6/22 2:03 PM (GMT+04:00) To: organicoman <organicoman_at_[hidden]> Cc: std-proposals <std-proposals_at_[hidden]>, Ville Voutilainen <ville.voutilainen_at_[hidden]>, Sébastien Bini <sebastien.bini_at_[hidden]> Subject: Re: [std-proposals] Relocation in C++ On Fri, 6 May 2022 at 09:38, organicoman <organicoman_at_[hidden]> wrote:The resource leaks. But that's fully defined behavior; you can accomplish the same by an unpaired resource acquisition: int main() { new int; } is a perfectly valid program.Yes, in the above example, terminating the program will take care of freeing the resource. My question is, what strong guarantee the "Relocation" concept will provide? In other words, what should I watch for? Since the closing curly baces will not mean "calling destructor" necessarily. The resource will continue to be managed, but by a different object; the lvalue object materialized from the prvalue relocated from the original owner lvalue. So it will be released when the new object's destructor is called.