[Development] qMoveToConst helper for rvalue references to movable Qt containers?

[André Pönitz]

On Sun, Oct 21, 2018 at 04:15:58PM +0200, Elvis Stansvik wrote:
> In order to try out the unsafe usage you suggested in your other mail,
> and also another unsafe usage pointed out in an SO question
> (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> I made the following test program.
> 
> The output when running is:
> 
> [estan at newton move-to-const-test]$ ./move-to-const-test
> without moveToConst:
> FooPrivate constr from vector
> Foo constr with arg 0x7fffdb627200
> Foo begin 0x7fffdb627200
> Foo end 0x7fffdb627200
> Foo destr 0x7fffdb627200
> FooPrivate destr
> 
> with moveToConst:
> FooPrivate constr from vector
> Foo constr with arg 0x7fffdb627208
> Foo move constr 0x7fffdb627210
> Foo destr 0x7fffdb627208
> Foo begin const 0x7fffdb627210
> Foo end const 0x7fffdb627210
> Foo destr 0x7fffdb627210
> FooPrivate destr
> [estan at newton move-to-const-test]$
> 
> Which just shows it's working as intended.

I have (a) no example that triggers obviously bad behaviour and (b)
a bad gut feeling nevertheless.

The problem is that a 'move' could be a 'swap' in practice, with the 
to-be-destroyed object held 'for a while', effectively turning C++'s
rather deterministic destruction behaviour into something resembling
garbage collection.

I wouldn't be surprised if one can cause real problems with 'random'
destruction orders on non-memory resources, like files. Simple memory
might be safe(r), as releasing order does typically not matter.

Andre'