On Fri, 17 Sept 2021 at 13:08, Richard Biener <richard.guent...@gmail.com> wrote: > > On Fri, Sep 17, 2021 at 1:17 PM Thomas Schwinge <tho...@codesourcery.com> > wrote: > > > > Hi! > > > > On 2021-09-10T10:00:25+0200, I wrote: > > > On 2021-09-01T19:31:19-0600, Martin Sebor via Gcc-patches > > > <gcc-patches@gcc.gnu.org> wrote: > > >> On 8/30/21 4:46 AM, Thomas Schwinge wrote: > > >>> Ping -- we still need to plug the memory leak; see patch attached, > > >>> and/or > > >>> long discussion here: > > >> > > >> Thanks for answering my questions. I have no concerns with going > > >> forward with the patch as is. > > > > > > Thanks, Martin. Ping for formal approval (and review for using proper > > > C++ terminology in the 'gcc/hash-table.h:hash_table::expand' source code > > > comment that I'm adding). Patch again attached, for easy reference. > > > > Ping, once again. > > I'm happy when a C++ literate approves the main change which I quote as > > new ((void*) q) value_type (std::move (x)); > + > + /* Manually invoke destructor of original object, to counterbalance > + object constructed via placement new. */ > + x.~value_type (); > > but I had the impression that std::move already "moves away" from the source?
It just casts the argument to an rvalue reference, which allows the value_type constructor to steal its guts. > That said, the dance above looks iffy, there must be a nicer way to "move" > an object in C++? The code above is doing two things: transfer the resources from x to a new object at location *q, and then destroy x. The first part (moving its resources) has nothing to do with destruction. An object still needs to be destroyed, even if its guts have been moved to another object. The second part is destroying the object, to end its lifetime. You wouldn't usually call a destructor explicitly, because it would be done automatically at the end of scope for objects on the stack, or done by delete when you free obejcts on the heap. This is a special case where the object's lifetime is manually managed in storage that is manually managed. > > What happens if the dtor is deleted btw? If the destructor is deleted you have created an unusable type that cannot be stored in containers. It can only be created using new, and then never destroyed. If you play stupid games, you win stupid prizes. Don't do that. > Shouldn't you use sth > like a placement 'delete' instead of invoking a DTOR? No, there is no placement delete. This is exactly the right way to destroy an object in-place. I haven't read the rest of the patch, but the snippet above looks fine.
