Wszyscy wiemy czym jest preprocesor Cpp i jak działa1. Jest to narzędzie odziedziczone z języka C, operujące na tekście kodu programu, a tym samym nie mające żadnego pojęcia o składni i regułach języka jaki przetwarza. Jest narzędziem, które używane nierozważnie może z łatwością doprowadzić do klęski nasz program. A mimo to wciąż tak wiele programistów piszących swoje aplikacje w C++ go kocha.
Nagminne używanie preprocesora jest też częstym nawykiem wyniesionym z C i nadużywanym w C++.
W nawiązaniu do poprzedniej notatki, niejakim uzupełnieniem przedstawionych tam informacji i zapowiedzi o dzieleniu się głębszymi przemyśleniami i odczuciami jakimi napełnił mnie kolejny przeprowadzony code-review, będą notatki przedstawiające nieco bardziej zaawansowane aspekty i techniki używane w C++.
Mam tu na myśli notatki traktujące o tytułowym “modern C++”, czyli nowoczesnym i zaawansowanym C++, gdzie głównie wykorzystywane są wzorce i metaprogramowanie. Nie powinno także zabraknąć innych zaawansowanych funkcji oferowanych przez język. Większość będzie silnie powiązana z maksymalnym wykorzystaniem biblioteki STL i boost.
Zacząłem małą restrukturyzację źródeł modułów. Dosłownie i w przenośni! Myślę, że wszelkie okna i GUI związane i korzystające usilnie z jakiegoś modułu powinno zostać wsiąknięte przez moduł doi środka. I to się właśnie dokonało. Wszelkie okna danego modułu przeniosłem do źródeł i przestrzeni nazw danego modułu.
Kolejną kwestią jest mała refaktoryzacja i ustalenie jakiegoś interfejsu każdego modułu. Odkąd GUI będzie częścią modułów to i interfejs się bardzo powinien uprości, bo powozili to także trochę logiki wrzucić do środka modułów.
Skusiłem się do napisania tej notatki w wyniku pogłębiającej się frustracji i zażenowania jakie mnie ogarnia, gdy po raz kolejny przeglądam jakiś dowolny kod źródłowy napisany, według jego autora, w C++. Niestety dosyć często zdarza się, że w rzeczywistości w ogóle to niewiele ma wspólnego z tym językiem. Zastosowane techniki i styl mówią coś zupełnie innego. Jedyne co może łączyć z językiem C++ to użycie rozszerzenia .cpp dla plików źródłowych, zamiast .
Kolejnym modułem jaki “leżał” na deskach roboczych był moduł ustawień, a dokładnie to moduł związany z samym okienkiem ustawień. Nazwa może wprowadzać małe zamieszanie bo jest już jeden moduł, który zajmuje się ustawieniami aplikacji i ich obsługą w plikach XML. Niniejszy moduł jest właśnie ściśle z nim związany, bo zajmuje się prezentacją ustawień w GUI. W sumie może lepiej pasowałaby tutaj nazwa menadżera opcji.
Jak to wygląda? Niestety nie mam żadnego screena, ale “szału” tutaj nie ma - typowe okno ustawień z drzewkiem grupującym opcje i odpowiadającymi im zakładkami.
Buffer overflow, czyli przepełnienie bufora jest jednym z najczęściej wykrywanych błędów w różnej maści oprogramowaniu. Błąd ten polega na zapisaniu do wyznaczonego obszaru pamięci większej ilości danych, niż zostało to przewidziane przez twórcę. Powoduje to nadpisanie sąsiadujących z buforem komórek pamięci, co w ostateczności prowadzi do różnych nieprzewidywanych zachowań aplikacji.
W najlepszym wypadku spowoduje to “wywalenie” się całego programu, a w najgorszym umożliwi przejecie kontroli nad maszyną przez włamywacza, który odpowiednio wykorzysta zaistniałą sytuację.
Ostatnio bawiłem się z prostą aplikacją embedując kontrolkę Internet Explorera oraz silnik Gecko. Po raz pierwszy miałem nieco szerszy i dłuższy kontakt z technologią COM i XPCOM. I przy okazji odkryłem ciekawą bibliotekę.
Nieodłączny związek z COM ma biblioteka ATL (Active Template Library), która w rzeczywistości jest zbiorem klas szablonowych języka C++ opracowanych przez Microsoft. Jak się można domyślić z nazwy, idea podobna jak w przypadku STL. Głównym zadaniem biblioteki jest ułatwienie korzystania i tworzenia komponentów w technologii COM.
Ostatnio pracowałem nad modułem menadżera kont oraz jego wizualizacją. Co z tego wyszło można zobaczyć na załączonym obrazku. Tym razem tylko spod Windows 7, gdzieś mam zrzut z Ubuntu, ale nie chce mi się szukać.
Mam nadzieję, że nie muszę tłumaczyć idei profili, kont i protokołów w tworzonym komunikatorze, gdzieś w początkowych notkach na tym blogu powinno być to wytłumaczone lub chociaż przedstawiony ogólny zarys.
Odnośnie samego menadżera kont mogę wspomnieć tylko tyle, że prócz tej prostej, ale funkcjonalnej wizualizacji kont, nic nie można (jeszcze) zrobić.
Dawno nic nie pisałem, a przyrzekłem sobie kiedyś, żeby nie zaśmiecać zbytnio technicznymi wpisami tego projektowego dziennika. Choć na samym początku, jednym z celów powstania tego bloga, obok przedstawiania i tworzenia na bieżąco historii projektu, było także ukazywanie różnych ciekawych sztuczek jakie zastosowałem w kodzie lub po prostu przedstawienie problemów na jakie trafiłem, licząc że ktoś będzie w stanie pomóc ;)
Zatem unikając czysto technicznych bzdur, ostatnio udało mi się zaimplementować bardzo prosty mechanizm pozwalający na zapisywanie i odczytywanie stanu poszczególnych okienek.
O systemie budowania aplikacji bakefile, generującym odpowiednie pliki dla narzędzi typu make i projekty dla różnych środowisk IDE, pisałem już w przeszłości. Jest to wspaniale narzędzie, szczególnie przydatne przy tworzeniu multiplatformowego oprogramowania.
Dosyć często zdarza się, że chcemy dorzucić do makefile jakieś niestandardowe reguły oparte na wykonaniu kilku poleceń w powłoce systemowej. Bakefile zawiera odpowiednie mechanizmy do takich celów - reguła action, która pozwala wykonać dowolną komendę lub polecenie, moduły do kopiowania plików, katalogów, drzew katalogów - moduł datafiles (dostarczany w standardzie z bakefile), tworzenie plików wynikowych lokalizacji (mo) opartych na gettext, i wiele innych.