Dziś kilka słów o mojej prostej strukturze TreeLinkedList.
Jest to prosta drzewiasta struktura, jak sama nazwa wskazuje można ją sobie wyobrazić jako skrzyżowanie drzewa z listą, a dokładniej to hierarchiczne powiązanie drzewem kilku list, gdzie każda gałąź jest listą elementów, które są kolejnymi gałęziami.
Twór ten jest bardzo zbliżony do B-tree, aczkolwiek nie posiada wszystkich cech tego typu drzew, jedynie strukturalne podobieństwo.
Najprościej byłoby przedstawić ideę graficznie, ale niestety moje predyspozycje graficzne oraz chęci są nikłe.
Kiedyś, prawie rok temu kombinowałem coś z dwuwymiarowymi tablicami dynamicznymi.
W projekcie xime, lista kontaktów wykorzystuje prostą implementację takowej tablicy opartą na małym rozszerzeniu standardowego wektora. Tablica ta odzwierciedla widoczne w danej chwili w kontrolce elementy, zawiera wskaźniki, bądź proste elementy z wskaźnikami do elementów kontaktów umieszczonych w powiązanym drzewie, coś w stylu B-tree.
Idea działania tablicy jest dokładnie taka, jaką opisano w wspomnianej notce, jako ostatnie rozwiązanie.
Miałem ostatnio chwilkę, to poprawiłem i doprowadziłem do porządku kod tablicy dwuwymiarowej używany w xime, aby można było go wykorzystać w dowolnym innym miejscu.
Szablony są bardzo elastycznym elementem języka programowania, a ich wykorzystywanie jest bardzo użyteczne.
Użycie ich pozwala redukować i minimalizować pisanie oraz powielanie kodu. Jak wiemy konkretyzacja dla danego typu wykonywana jest tylko do używanych metod w szablonach klas, przez co nie jest generowany niepotrzebny kod.
Niestety generowany kod wynikowy jest już nieco rozbudowany. Każda konkretyzacja szablonu jest osobna klasa, a dla każdej klasy generowany jest pełny kod potrzebnych funkcji. W przypadku konkretyzacji wzorca typem wskaźnikowym dla każdego rodzaju wskaźnika zostanie wygenerowany “inna” klasa a wraz z nią “podobny” kod wynikowy.
Nic nie jest doskonałe. Tak samo C++ i STL ma swoje braki i różne przeoczenia. W standardowej bibliotece języka C++ zabrakło bardzo użytecznego algorytmu, jakim jest copy_if, czyli kopiowania z predykatem.
Prawdopodobnie został on usunięty przez przypadek z dostarczanych przez bibliotekę algorytmów generycznych. Na szczęście z tego co się orientuję, można znaleźć o nim wzmianki w drafcie nowego standardu (C++0x), także jest szansa, że błąd ten zostanie naprawiony.
Tymczasem, jeśli jest potrzeba, to można korzystać z bardzo prostej implementacji tego algorytmu:
Obecnie pracuję nad listą kontaktów, ale tak tylko wspominam, bo nie o tym dziś chciałem poinformować.
W projekcie cały czas coś się dzieje. Może zmian widocznych nie ma za wiele, ale praca idzie pełną parą. Aby nie być gołosłownym napisałem sobie mały, prosty skrypt, który generuje logi z lokalnego repozytorium SVN, gdzie trzymany jest cały projekt, a następnie wysyła je na serwer.
Logi dostępne są pod adresem xime.pl/svnlog.txt i są automatycznie aktualizowane co 24h, o północy każdego dnia.
Często pracując z konsolą przydaje się możliwość, aby do najczęściej używanych programów i narzędzi dostawać się poprzez wprowadzenie jego nazwy w wierszu poleceń, niezalenie od bieżącej lokalizacji. Żeby coś takiego działało to dany program musi znajdować się w katalogu, którego ścieżka zawarta jest w zmiennej systemowej PATH, określającej listę lokalizacji jakie zostaną przeszukane przez interpreter poleceń w poszukiwaniu pliku wykonywalnego.
Jednym z rozwiązań jest trzymanie wszystkich aplikacji i plików wykonywalnych w jednym katalogu, ale to w przypadku systemu Windows jest chybionym pomysłem.
Do tej pory w xime, jak też w kilku innych komunikatorach, profile opierały się na liście profili zapisanej w jednym pliku oraz strukturze katalogów, gdzie dla każdego profilu istniał katalog, w którym przechowywano wszelkie dane.
Przechowywanie podstawowych danych o profilu w postaci listy w jednym miejscu miało swoje zalety. Taką zaletą była niewątpliwie łatwość i szybkość przetwarzania informacji. Nie było skakania po katalogach i parsowania wielkich plików konfiguracyjnych każdego profilu w celu zbudowania prostej listy dostępnych profili.
Błędy były i będą, tak samo jak ich zwalczanie i ciągłe testowanie. To nieodłączna część świata programistów. Testowanie jako jeden z etapów konstrukcji i projektowania oprogramowania powinien być obowiązkiem każdego programisty.
Błędy dają o sobie znać w najmniej oczekiwanych momentach, doprowadzając do frustracji, a czasami i furii użytkowników, testerów i programistów. Dlatego tak ważne jest, aby z nimi walczyć najszybciej jak się tylko da.
Jednym ze sposobów walki z błędami są testy jednostkowe (unit test).
O potędze skryptów automatyzujących pracę (nie tylko programisty) i wszelkich makefile-ach można byłoby długo mówić i pisać. To one przyśpieszają i ułatwiają pracę, często wykonując powtarzane żmudne jej elementy i czasem pomagając zapomnieć o wklepywaniu niekończących się linii w konsoli.
Osobiście do tej pory rzadko mi się zdarzało pisać ręcznie pliki z regułami dla make-a, a to głównie dzięki używaniu Code-Blocks jako cross-platformowego IDE. Ostatnio się to jednak trochę zmieniło poprzez bakefile, które używane jest m.
Pod zwirtualizowanym Leopardem 10.5.2 xime również bez większych problemów się skompilowało i uruchomiło.
Tak szczerze to były jakieś małe problemy z uruchomieniem aplikacji, jak również z kompilacją biblioteki wxWidgets pod Mac-kiem. Dlatego, głównie z tego drugiego powodu, na razie system spod znaku jabłuszka nie będzie wspierany.
Być może to bardziej były jakieś moje problemy z wx-ami. Wersja oparta na Carbon nie zbyt chciała działać, a pod Cocoa miałem wrażenie jakby w tym porcie brakowało trochę “rzeczy”.