Practicality of a C++ proposal to add memory move semantics for certain objects?

Ewan already wrote in a comment: the memory address of a C++ object never changes during its life time. Objects are created, copied and destroyed (assignment is just a special form of copying where the internals of a destination are overwritten). Hence, there is no "event" inside C++ which would make Foo::onMemoryMove be called.

Containers like vectors (and probably a QList, though I am not a Qt expert) may create the illusion of objects being "moved" inside the container, but what they actually do is either copy and delete the objects, or store objects indirectly through pointers (so the pretended order of objects in such a container can change without having to copy them). So a direct "move" of an object, when not implemented by a pointer assignment, will always cause a call to a copy constructor and another call to a destructor (or it may cause the call to an assignment operator, which does the equivalent of both in one).

Even "move semantics" does not really "move" objects in memory. Quite the opposite - it provides a way to pass existing pointers from an rvalue object into a newly constructed object and keep the existing memory locations where they are.

Please don't confuse can't with shouldn't.

Can you find a way to move objects around in memory without using constructors or destructors? Absolutely. Many schemes for defragmenting heap memory, and the objects it contained have existed over the years. Every object IS memory. At least when you look at it a certain way.

However, looking at them this way breaks the metaphor you've been using when letting the language manage object creation and destruction. Many of the guarantees and assumptions go poof when you do things like this.

I was taught about this idea changing an objects address decades ago by one of the guys on the C++ steering committee. The big thing keeping them from generalizing a scheme for letting you do this in the language isn't anything I've heard anyone here mention.

The problem is users get to design whatever objects they want. And one of the kinds of objects they can design is called 'self aware'. This is an object that has a reference or pointer to itself. So if you want to go shoving your object pool around in memory you now have to know which kind of object you have or you're gonna break it.

At the time he was telling me about this they were playing with the idea of inventing a kind of pointer that would get updated when moved. Far as I can tell though this idea never really matured. I suspect the reason why is about that same time we invented defragmenting schemes that didn't require moving things around. Defragging was the only use case they had for this kind of move. It's so much easier to move pointers and references around. Why move the big clunky object? Which meant it was suddenly a purely academic problem.

So yeah, likely a bad idea. But I really doubt it's impossible.

The object to put your onMemoryMove method on to achieve what you want to do is QList QList is a special list:

QList is one of Qt's generic container classes. It stores its items in adjacent memory locations and provides fast index-based access.[...] QList's value type must be an assignable data type.

If you reorder or change the QList's data you are relying on its internals on what it actually does. It might make a whole new memory allocation, or over write its current data, the data in the list might be pointers to other data etc etc. There's no way for the data to know its "moved"

But you can wrap or override QList and change the methods which reorder the data to keep track of the index in the list and update a QSet or other data structure.

To answer your direct question "Should data moving handles be a language feature?". You don't make a good case for it.

it seems practical for my use case

Not really.

1. OOP already covers your use case, in the way I detail above
2. Your case is very specific to QList, which orders the data in memory in the same order as the object's index. But not all lists and collections do this.
3. What do we mean by "moving memory location"? if I copy the data to a new location, so now I have two copies, does that count as move? what if I delete the first copy? is it moved now? We don't really have guarantees about what QList does under the hood. It could change between versions and compilers. "move" in your use case has the meaning of "changing index in the QList" but QList might not "move" the data type in the way the language feature considers "moved memory location"

for example you say:

m_FooList.takeFirst(); // Causes all Foo::onMemoryMove to be called

But maybe QList just updates its own start data location to the second item in the list instead of moving all the data up one. The index of each item would have changed, but the memory locations would all still be the same.