Testowanie nieprawidłowego uchwytu okna: czy powinienem porównać z "NULL", "0" lub nawet "nullptr"?

Question

Pochodzę z tła, w którym wskaźniki powinny być zasadniczo porównywane z "NULL" i liczbami całkowitymi z "0".

Ponieważ nie postrzegałem uchwytów Windows jako "wskaźników" w czystym tego słowa znaczeniu (będących "uchwytami"), nabrałem nawyku porównywania ich z 0, a nie "NULL".

Najwyraźniej są one obecnie wdrażane wewnętrznie jako wskaźniki, ale osobiście uważam, że są one przeznaczone jedynie do uzyskania pewnego rodzaju bezpieczeństwa, a nie dlatego, że są wewnętrznie wskazówkami.

W każdym razie zauważyłem, że pomoc dla CreateIC, która zwraca kod HDC, stwierdza, że ​​w przypadku niepowodzenia funkcji zwróci wartość "NULL".

Teraz jestem zdezorientowany - i zastanawiam się, co inni ludzie sądzą - czy bardziej słuszne wydaje się rozważenie uchwytu systemu Windows jako wskaźnika (a zatem sprawdzenie go pod kątem "NULL" lub "nullptr" dla współczesnych kompilatorów) lub należy uznać, że jest liczbą całkowitą?

Answer 1

Porównaj to z udokumentowaną wartością zwracaną błędu. Oznacza to, że powinieneś porównać to z INVALID_HANDLE, 0, -1, niezerowym lub <=32 (nie żartuję z ostatnim, zobacz ShellExecute).

Answer 2

Wydaje mi się, że INVALID_HANDLE_VALUE jest zazwyczaj prawidłową "nieprawidłową" wartością dla uchwytów Windows ... i która ocenia się na -1.

Answer 3

Aby odpowiedzieć na to pytanie: typ HANDLE jest zadeklarowana w WINNT.H jak

typedef PVOID HANDLE; 

Stąd technicznie jest to wskazówka.

Jednak użyłbym tylko tego, co jest udokumentowane; jeśli dokumentacja stwierdza, że ​​zwracana jest nazwa NULL, używam jej dokładnie, chyba że dowody wskazują, że dokumentacja jest nieprawidłowa.

Nie myślę nawet o wskaźnikach w stosunku do liczb całkowitych. NULL jest po prostu nieprzezroczystą wartością (w tej sytuacji) i HANDLE jest dla mnie nieprzejrzystym typem i nie zadaję sobie trudu sprawdzenia, co to jest #define.