RSS

Pisanie w Win32 API jest proste

Liczba odsłon: 36

Od wielu miesięcy pracuję nad spo­rym progra­mem obliczenio­wym. Olbrzymia większość kodu odpo­wiada za struk­tury danych oraz algo­rytmy nume­ryczne; niewielki frag­ment obsługu­jący inter­fejs użytkow­nika został napi­sany – z wygody – z wykorzys­taniem biblio­teki .NET (język C++ w odmianie nadzoro­wanej).

Niedawno okazało się jednak, że pewne biblio­teki nume­ryczne, służące do szybkiego rozwiązy­wania wielkich układów równań linio­wych, są niezgodne z rozszerze­niami nadzorowa­nymi C++, wprowadzo­nymi przez firmę Microsoft. Konieczne stało się przepi­sanie kodu obsługi inter­fejsu użytkow­nika do „czystego” C++, a to ozna­czało przejście na poziom Win32 API.

Dawno już nie programo­wałem bezpoś­rednio w API. Zazwyczaj wykorzystuję własną, „lekką” biblio­tekę obiek­tową ukrywa­jącą poziom API pod płasz­czem eleganckich klas. Efektem jej stoso­wania są małe, szybko działa­jące programy, pisane w sposób bardzo wygodny — prawie, jak z wykorzys­taniem bibliotek typu VCL czy .NET.

Teraz, gdy musiałem wrócić do korzeni i znów ręcznie rejestrować klasy i tworzyć okna (praca w zespole raczej wyklu­czała stoso­wanie własnego zestawu biblio­tek), utwier­dziłem się w przekonaniu, że to wcale nie jest takie trudne. Ba, czasem kod programu jest nawet bardziej zwarty: tam, gdzie nowo­czesne biblio­teki wymu­szają stoso­wanie obiektów i dziedzi­czenia, w API wystarczy wywo­łanie kilku pod­prog­ramów.

Oczywiście, im większy program tym mniej atrak­cyjne staje się bezpoś­rednie wykorzysty­wanie API. Programy przetwarza­jące dziesiątki komuni­katów i zawiera­jące w swoich oknach setki obiektów steru­jących mogą szybko stracić na czytel­ności i stać się kosz­marem w razie koniecz­ności wprowa­dzenia zmian. Apeluję jednak: jeżeli piszecie niewielki graficzny program dla Windows, zanim sięgnięcie po kolub­ryny w rodzaju C# czy Java — dajcie szansę pros­temu, szyb­kiemu i oszczęd­nemu Win32 API.


A co z inną kolubryną (ach, ja zawsze mówiłem i pisałem "kolumbryna", człowiek się uczy, a Firefox podkreśla ;) ), MFC? W ogóle ktoś z tego korzysta jeszcze, korzystał? Miałem przyjemność (nie, naprawdę, przyjemność z pewnymi wyjątkami, o tym za chwilę) korzystania z tego z dwa lata temu przy średniej wielkości projekcie i tak źle nie było. Do wyboru mieliśmy C++ i C# i padło na C++ ze względu na zarządzanie pamięcią (aż tak duże wykorzystanie pamięci by nie było :/). Tak czy inaczej, w MFC pisało się całkiem sprawnie, dopóki nie trzeba było zrobić czegoś naprawdę specyficznego, dziwnego, ale i wtedy były całkiem wygodne furtki na to. W C# słyszałem (dużo się nie bawiłem), że raczej są z niektórymi takimi rzeczami problemy (oj już nie pamiętam dokładnie, o co chodziło, ale chyba o dosyć specyficzne ComboBoxy). Z kolei jeszcze wxWidgets istnieje, który pięknie zamyka API w klasy, jest wieloplatformowy i bardzo wygodny (wiele rzeczy, które nawet w MFC trzeba ręcznie robić, są gotowe i opcjonalnie do wykorzystania), ale też cierpi na utrudnione dostanie się do bebechów i zrobienie rzeczy innych, no chyba że się chce sporo rzeczy i tak samemu pisać.

A Win32 API. Fakt że jest proste i sporo rzeczy można raz dwa zrobić i sam często korzystałem z niego przy robieniu prostych programów, gdzie potrzebne były z dwa okienka dialogowe i ewentualnie jakieś menu. Ale jeśli ktoś z niego nie korzystał, a zna inne rozwiązania, w których wie, że szybko coś zrobi, a ma także świadomość, że to jeden taki przypadek na tysiąc, to czy jest sens poznawać Win32 API? Może analogia do przechodzenia np. z C do assemblera by była przesadą, ale trochę tak to widzę ;) Ale jeśli ktoś w assemblerze szybciej napisze program niż nauczy się C, to też nie ma sensu, by w C coś robił ;)
MFC ma się cały czas całkiem nieźle ze względu na szerokie wykorzystanie w komercyjnym oprogramowaniu. Wadą MFC jest olbrzymia zależność od Win32, skutkująca niewielką abstrakcją tej biblioteki. Paradoksalnie, jest to również jej największa zaleta, ponieważ – jak zauważasz właśnie – w MFC można zrobić praktycznie wszystko, zawsze mając furtkę w postaci bezpośredniego dostępu do filtrów komunikatów.
Języki .NET są mocniej odsunięte od Win32 (a nawet całkowicie odchodzą od tego API — WinFX).