Hi Jonathan and thanks again for your kind replies. On 10/23/14, Jonathan M Davis via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote: > That will result in a move operation. No copying will take place. > And it technically, it may not actually move anything it all and > just use the object where it's initially constructed. I'm not > sure what the actual, generated machine code ends up doing in > that regard. But there's no copying or double-construction.
Well blitting is copying isn't it? I read your SE answer where you define a move as a blit without the postblit. Hmm. Somehow the name "move" seems to be misleading... To clarify that, is this the same as the C++11 move behaviour or is it subtly different? IIUC in case of a C++ vector, a move would mean that the length and possibly other direct members of the class including the pointer to the heap-allocated managed data would be copied to the target (same as blit I guess) and the managed data itself is not dupped (i.e. postblit is not called) and we call it a move, yeah? But it's actually better called a shallow copy, no? Or is a shallow copy different from a move in any other way? > const does _not_ mean that a copy doesn't need to be made. It has > zero effect on that. In fact, if you're passing an lvaue to a > function that doesn't take its arguments by ref, it's almost a > guarantee that a copy will be made. The only exception would be > if the compiler determines that the lvalue in question is never > used after that call, in which case, it might just move the > object rather than copy it. But that doesn't seem logical. If the compiler is able to determine that the lvalue in question is not modified in the function at all (either heuristically or by the programmer defining it as "in" or "const") then it should be able to optimize by not even making the move aka shallow copy, no? Of course I understand it doesn't *have* to do an optimization, and that D believes that ideally optimization opportunities should be recognized and acted upon by the compiler and the user should not need to specify places where this is possible (I listened to the Andrei/Walter panel talk where IIUC they were saying this is the ideal behaviour and keywords like "pure" "nothrow" etc shouldn't ideally be needed), but I just want to be sure whether I'm understanding right that there is indeed the possibility in the present case. > So, you mean if draw was a member function of Bezier, and you did > something like > Bezier(100, 100, 133, 200, 166, 200, 200, 200).draw() > you want to know whether a copy of the Bezier object would be > made? The this member of a struct is a ref - in this case ref > Bezier - so it doesn't make a copy. Actually it doesn't even make a move aka shallow copy right? If that's right, then sorta here we are seeing how a ref to a temporary can indeed exist, i.e. implicitly within the member functions. (I'll post separately on that topic.) > If draw is a free function, then > Bezier(100, 100, 133, 200, 166, 200, 200, 200).draw() > is literally transformed into > draw(Bezier(100, 100, 133, 200, 166, 200, 200, 200)) > by the compiler, so the behavior of those two lines is identical. > And as I said above, that means that a move is made. OK so if I read this right, if the function is defined as a free function, then calling it on a temporary will make a shallow copy (and I can't use an explicit ref on the temporary argument), but if it is defined as a member then calling it on a temporary will not even make a shallow copy. Because of UFCS, how I'm *calling* the function will not have an effect on whether the shallow copy is made or not, but how I *defined* it will. Correct? > I'm not sure why it would sound presumptious if you're asking > whether you're understanding or guesses about how D works are > wrong. Questions are certainly welcome. That's very nice of you. I only added the advance apology because sometimes some friends of mine have commented that I come across high and mighty in saying "this should be like this and this and not like that" in technical fora where people more knowledgeable than me exist. As Andrei said in his opening address, it's nice to see that one big strength of D is the patient and friendly replies of the D community. :-) -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा
