Makro SendMessage a nazwa funkcji

tech • 312 słów • 2 minuty czytania

W notce Makra WinAPI i problemy z nazwami przedstawiłem proste i łatwe rozwiązanie problemu wynikającego z wykorzystania nazwy SendMessage w definiowanej funkcji pod Windowsem. Rozwiązanie to jest brzydkim hackiem i obejściem problemu, ale działa… i zawiera też kilka wad.

Główną wadą jest wymóg dołączenia nagłówka windows.h do projektu, tuż przed nagłówkami biblioteki, w której chcemy zadeklarować funkcję o nazwie SendMessage(), a w skrajnych przypadkach (chyba w każdym) nawet do pliku/projektu tej biblioteki. Nie będzie to wielkim problemem, jeśli program będzie korzystał z WinAPI.

Gorzej, jeśli program będzie budowany na platformę Windows, ale nie będzie bezpośrednio wykorzystywał WinAPI i windowsowych nagłówków. Wtedy i tak trzeba będzie “includować”, w istocie dla programu niepotrzebny, windows.h, a co za tym idzie, cały szereg innych systemowych nagłówków, co może także prowadzić do jakiś konfliktów i błędów.

Wadą jest też zaciemnienie sobie własnego kodu, interfejsu, deklaracji, definicji tym preprocesorowym hackiem…

Nie ukrywam, że nie podobało mi się tamto rozwiązanie, bo ani to idealne, ani uniwersalne. Dlatego dzisiaj przy napływie miliona myśli na sekundę, wróciłem do tego problemu i znalazłem inne, lepsze, pozbawione tych wad.

Do problemu podszedłem od drugiej strony. Zamiast machać preprocesorem przy definicjach i deklaracjach, lepiej odwzorować zachowanie WinAPI-owskiego makra i dołączyć go do projektu. W tym celu, w głównym nagłówku projektu, bądź w miejscu deklaracji naszej funkcji SendMessage dorzucamy kod:

// Fixed SendMessage function name problem on Win32
#if defined WIN32 && !defined SendMessage
	#ifdef UNICODE
		#define SendMessage SendMessageW
	#else
		#define SendMessage SendMessageA
	#endif
#endif

Teraz będziemy mieli pewność, że pod system Windows, niezależnie od dołączenia systemowych nagłówków w kodzie programu wykorzystującego bibliotekę, zachowanie będzie spójne - wszystkie wystąpienia nazw zostaną zawsze przetransformowane i nie będzie konfliktu, ani braku zgodności nazw pomiędzy różnymi częściami projektu.

Rozwiązanie to jest prostsze od poprzedniego, do tego uniwersalne, bez dołączania nie potrzebnych nagłówków i zaśmiecania sobie interfejsu, bo wystarczy to wrzucić w jakieś jedno miejsce w kącie projektu ;)

Komentarze (0)

Dodaj komentarz

/dozwolony markdown/

/nie zostanie opublikowany/