Windows jak każdy inny system również da się w bardzo łatwy sposób oskryptować. Nie wszyscy mają pojęcie na ile sposób i możliwości można to zrobić. To nie tylko babranie się w powłoce systemowej, która niektórym kojarzy się tylko i wyłącznie z dawnymi czasami panowania DOS-a lub przywilej systemów uniksopodobnych. Dlatego w najbliższych notkach przedstawię kilka możliwości i sposobów jakie oferuje system Microsoftu w sferze skryptowania i ułatwiania sobie życia. Sam używam głównie tego systemu, ale bez automatyzacji i skryptów moja praca pewnie byłaby dużo cięższa, a na pewno mniej wygodna i komfortowa.
Wreszcie udało mi się sprężyć z robotą i zakończyć prace nad modułem listy kontaktów. Być może przesadzam z tym zakończeniem prac, bo nie wszystko co na początku było planowane zostało zrobione. Aczkolwiek myślę, że nie ma potrzeby przeładowywać funkcjonalnością, która tak naprawdę nie jest jakoś bardzo potrzebna.
Aby nie zostać posądzonym o kłamstwo to wypada pokazać jakiś dowód na poparcie swoich słów. Zatem poniżej prezentuję zrzut ekranu z testowej aplikacji listy kontaktów.
Perl, czyli “Practical Extraction and Report Language”, często też bywa rozwijany do “Pathologically Eclectic Rubbish Lister”. Ciężko jednoznacznie stwierdzić, które rozwinięcie nazwy jest bliższe rzeczywistości, ponieważ oba zostały zatwierdzone przez jego twórcę Larrego Walla.
Zastanawiające może być to, dlaczego ludzie tak nie lubią i nienawidzą Perla? Do tego często niektorzy go wszystkim odradzają, szczególnie początkującym, na rzecz Pythona, który w ostatnich czasach zwiększył swoją popularność, chociaż nie jest on wcale takim młodym językiem.
Dosyć często używam narzędzi dostarczanych z Visual Studio spod linii poleceń, głównie nmake do budowania z wykorzystaniem plików makefile. Nieraz jest to bardziej wygodne i optymalne w pracy od odpalania i zabawy z IDE.
Standardowo przy odpalaniu Visual Studio 2008 Command Prompt wykonywany jest skrypt vcvarsall.bat, który ustawia środowisko, czyli odpowiednie zmienne środowiskowe, ścieżki… Wszystko fajnie i cacy, ale przy ustawieniach ścieżek do nagłówków i bibliotek nie są brane pod uwagę pozycje zapisane w ustawieniach IDE.
Boost.bind to potężne narzędzie. Dzięki niemu możemy pozbyć się wielu prostych i trywialnych, a także tych trochę bardziej skomplikowanych funktorów, jakie musieliśmy definiować, bo standardowe adaptery funkcyjne z STL są ograniczone. Za niedługo zobaczymy bind-a w standardzie, a obecnie dostępny jest w TR1.
To za jego sprawką z kodu źródłowego xime zniknie kilka predykatów. Zostaną zastąpione jedno-dwu linijkowymi złożeniami bindowych adapterów i obiektów funkcyjnych. Kod stanie się bardziej czytelny i spójny, bo nawet prosty predykat wykorzystujący jakiś element lub metodę obiektu definiowany jest jako klasa funktora, co przy kilku dodatkowych definicjach klas powoduje rozrastanie się kodu.
Zbiór gotowych algorytmów ze standardowej biblioteki języka C++ jest bardzo użyteczny, o tym nie trzeba długo nikogo przekonywać. Choć czasem, gdy trzeba wykonać kilka rzeczy naraz, bądź kilka kolejnych algorytmów na tych samych danych, możemy stracić na wydajności, szczególnie jak danych jest wiele, a złożoność algorytmu liniowa.
Czasem warto trochę pomyśleć i napisać coś dedykowanego, ewentualnie połączyć 2 algorytmy. Oczywiście tylko, jeśli jest to możliwe i w miarę proste, np. gdy oba algorytmy mają podobną budowę.
Za niedługo upłyną 3 miesiące od ostatniej notki dotyczącej projektu xime.
Mam nadzieję, że do tego czasu uporam się z listą kontaktów, bo to właśnie z nią się męczę obecnie w wolnych chwilach. A czasu nie jest za dużo, bo ostatnio sesja, praca dyplomowa, no i prócz tego zwykła, codzienna praca…
Pracuję nad listą kontaktów i chciałbym jej implementację jak najszybciej zakończyć. Z tego powodu muszę zrezygnować z większości planowanej funkcjonalności, która de facto i tak związana będzie z API umożliwiającym wtyczkom “wywieranie” w znacznym stopniu wpływu nie tylko na wygląd, ale także na zachowanie i funkcjonalność.
Od wersji 2005 Visual C++ posiada opcję sprawdzania ważności iteratorów. Może to być przydatna funkcjonalność, która powoli uchronić się przed typowymi błędami związanymi z niepoprawnym użyciem iteratorów. O szczegółach działania można poczytać na stronach MSDN w kilku ciekawych artykułach: Checked Iterators, Debug Iterator Support.
W uproszczeniu mówiąc, przy włączonym Debug Iterator, program w wersji debug poczęstuje nas assertami, kiedy spróbujemy wykonać jakąś operację na niepoprawnym (unieważnionym1) iteratorze lub funkcji go wykorzystującej.
Często w programach napisanych w C do pobierania rozmiaru tablic (ilości elementów) alokowanych przez kompilator na stosie stosuje się prostą konstrukcję z operatorem sizeof. ładnie “opakowaną” w makro do łatwego użycia:
#define SizeOfArray(array) sizeof(array) / sizeof(array[0]) W C++ zamiast makra lepiej wykorzystać wzorzec, a wtedy można to przedstawić w takiej postaci:
template<typename T, size_t N> inline size_t SizeOfArray(const T (&)[N]) { return N; } Wersja cpplusowa jest bezpieczniejsza. Próba wywołania SizeOfArray() na wskaźniku zakończy się błędem w czasie kompilacji, w przeciwieństwie do makra, które dopiero da znać o tym problemie w run-time.
Przygotowuję się do małej prelekcji, taki krótki wykład i przedstawienie prezentacji związanej jakoś z moją pracą dyplomową, czyli ogólnie o komunikacji sieciowej. Pomyślałem więc, że opowiem o komunikacji natychmiastowej. A poznając trochę dogłębniej historię zmieniłem nieco dotychczasowy punkt widzenia w tym kierunku.
Kiedyś czułem lekkie oburzenie związane z tym, że AOL posiada amerykański patent na komunikację natychmiastową, a określenie “instant messenger” jest zastrzeżonym znakiem tej korporacji. Mimo iż firma na razie nie zamierza egzekwować patentu, użycie nazwy “instant messenger” w oprogramowaniu innym niż AOL-owskie jest zabronione i pociągnięte do odpowiedzialności.