On Sunday, 14 February 2016 at 12:53:08 UTC, Lars T. Kyllingstad wrote:
> I know you said afterwards you didn't need a reference, but I'll give you one anyway. :)  That is the formal requirement for C++ standard library types; see sec. 17.6.5.15 [lib.types.movedfrom] of the C++ specification.

k thx. ;-) (I'll look at it later)

> For your lowest-level resource owners, I guess that is the case.  But if a and b are largeish compound types that don't fit in a register, that's not the case, right?  Or can the optimiser deal with this in a good way too?

This is where measuring different compiler switch setups starts to matter, inlining and also cache effects... :-)

I don't think the size matters, for swap, except for potential cache misses. As long as there are no barriers you can just swap field after field. If the loop is tight, then the loop is unrolled inside the CPU before the micro-ops are scheduled into the pipeline IIRC.

> That is of course very unfortunate, but I guess it can be worked around?

You can work around it by having extra pointers/containers in or held by the struct (pointers to the source that is pointing to you). But that takes more space.

On Sunday, 14 February 2016 at 14:12:09 UTC, Ola Fosheim Grøstad wrote:
> You can work around it by having extra pointers/containers in or held by the struct (pointers to the source that is pointing to you). But that takes more space.

In the not-multithreaded version. In the multithreaded version you would have to use a heap allocated object that does not move and put the mutex there.

If std.move(x) wipes out x, without checking mutexes first... well, that can't work well with multi-threading. I guess you could avoid using std.move(x) and use a different function, but how do you ensure that?