Using in as a parameter qualifier

[Shriramana Sharma via Digitalmars-d-learn]

Hi Jonathan and thanks again for your kind replies.

On 10/23/14, Jonathan M Davis via Digitalmars-d-learn
<digitalmars-d-learn at 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 ஶ்ரீரமணஶர்மா श्रीरमणशर्मा