c - Returkonvention i vinduer

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg stødte på denne funktion:


DWORD WINAPI GetWindowThreadProcessId(
  \_In\_      HWND    hWnd,
  \_Out\_opt\_ LPDWORD lpdwProcessId
);


GetWindowThreadProcessId:



  • hWnd [in] (Håndter til et vindue)

  • lpdwProcessId [[ud, valgfri]]

  • Retur: DWORD.



Dette er en funktion, der får input som et håndtag til et vindue og en pointer.


Når den vender tilbage, holder *pointer PID'en til den proces, som hWnd tilhører.
Returværdien er TIDEN for den tråd, som hWnd tilhører.


Hvad gør MS-ingeniører, der vælger at returnere TID'en som returværdi, og skriv den til den adresse, der er angivet som en parameter, PID? Hvorfor ikke den anden vej? Returner PID og skriv TID? Hvorfor ikke vende tilbage både i en peger til en struktur, der indeholder strukturen {TID, PID}?


Hvad styrer disse valg? er der logik bag det?

Bedste reference


Windows ejes af tråde og tråde ejes af processer.


Hvis du kun vil have tråd-id'et, vil du ikke spildt nogen gang at få proces-id'et. Og hvis du vil have proces ID, skal du først få tråd-id'et.


Dette kort direkte til GetWindowThreadProcessId API:



  • Hvis alt du har brug for er tråd-id, kan du bede om det og ikke betale omkostningerne ved også at kigge på proces-id'et (ved at indstille lpdwProcessId til null).

  • Hvis du har brug for proces-id'et, er der ingen skade i at få tråd-id'et, da det er et nødvendigt mellemliggende trin.



Så jeg håber det forklarer, hvorfor det returnerer TID og indirekte gemmer PID'en via en peger (og ikke omvendt). Dette skal også gøre det klart, hvorfor det ikke returnerer en struktur med begge værdier.


Hvorfor ikke have to separate funktioner: GetWindowThreadID og GetThreadIDProcessID? Hvis du har brug for tråd-id, ringer du først, og hvis du har brug for proces-id'en, ringer du begge. Mit gæt er, at GetWindowThreadProcessId kan gøre det andet trin lidt mere effektivt end hvis du skulle gøre det som et særskilt skridt.