Rectangle CopyRect or =

[gromit]

Hi All
Old Win32 API Stuff
CopyRect(&g_panrec,&rc);
will copy the four coordinates from RECT rc into RECT g_panrec
However
g_panrec=rc will also do the same

So whats the Diference between CopyRect and Just 1 = the other ?

Speed ? memory use ? etc
I would like to know your views on the correct way to do this
BTIA gromit

[Bitbeisser]

I haven't done any graphics programming in Windows myself yet, and don't really look forward to.
But looking at the definition of CopyRect on MSDN, I think that you might have a couple of misunderstandings of the (less than subtle) difference between using the function (CopyRect) and "1= the other".

The function is transferring the data from the memory area pointed to by rc to the memory area pointed to by g_panrec. That's also your first misunderstanding, as the second parameter (rc) is the source and the first parameter (g_panrec) is the destination

Code: [Select]

Syntax

BOOL CopyRect(
  __out  LPRECT lprcDst,
  __in   const RECT *lprcSrc
);

Parameters

lprcDst [out]

    Pointer to the RECT structure that receives the logical coordinates of the source rectangle.
lprcSrc [in]

    Pointer to the RECT structure whose coordinates are to be copied in logical units.
As you can see, both a parameters are defined differently, so there a chance that
a) the function in fact is doing more than just a simple memory transfer
b) the two structures are of different size, which can lead to unforeseen side effects (bugs, ever heard of "buffer overflow"?)

With the assignment you mentioned however, you are just assigning (even when doing it the right way around) the value of the source pointer to the destination pointer, so both pointers now direct any further access to the same area of memory. That is certainly not what you want to do, specially not when you have to consider option b) from above, that the structures those pointers point to are of different size...

Ralf

[gromit]

Thanks for Your Reply Ralf


The function is transferring the data from the memory area pointed by rc to the memory area pointed to by g_panrec. That's also your first misunderstanding, as the second parameter (rc) is the source and the first parameter (g_panrec) is the destination


No misunderstanding and no disrespect intended.
But nowhere in my post does it say that i am doing it the other way round
Please read it with the emphasis on the highlighted text above

They are both existing RECT structs
and so have four coordinates each
and when 1 is assigned to the other they now have the same coordinates
when CopyRect is used it uses the addresses of the rect variables to make that copy
and they now both have the same coordinates???

i cant see a memory gain there so am a bit lost as to why both work seemingly ok

[CommonTater]

What we don't know, without seeing the source code, is whether there is some degree of error checking in CopyRect() that you won't get by simply assigning.  The function has a pass/fail return value so it would be reasonable to assume it does.

CopyRect on MSDN

[TimoVJL]

CopyRect just check if both parameters exists.
(You can check that with debugger)

Code: [Select]

CopyRect:
mov edi,edi
push ebp
mov ebp,esp
push edi
mov edi,dword ptr [ebp+8]
xor eax,eax
test edi,edi
je L75132551
push esi
mov esi,dword ptr [ebp+C]
test esi,esi
je L75132550
movsd
movsd
movsd
movsd
inc eax
L75132550:
pop esi
L75132551:
pop edi
pop ebp
ret 8

[Bitbeisser]

Sorry for my mistake about the order in which you tried to copy/assign, I looked over it at least a couple of times and could have sworn I saw it the other way around... 

As for my suggestion to be cautious, this was mainly due to the fact that the MSDN docs define  the destination struct as LPRECT and the source as RECT. I did not check further in the definition of those two but using different definitions would not be necessary if there would not be the possibility of a (subtle) difference between those two...

Ralf

[CommonTater]

CopyRect just check if both parameters exists.
(You can check that with debugger)

Thanks Timo... much appreciated.