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”.
Może trochę spóźniony prezent gwiazdkowy, ale xime kompiluje się i działa bez problemu pod Linuksem.
Jedynym istniejącym problemem jest kodowanie polskich znaków, zawartych na sztywno w kodzie. Stringi w wxGTK reprezentowane są wewnętrznie w postaci UTF-8, więc mamy krzaczki przy zapisie źródła w innym kodowaniu. A jak zapiszemy w UTF-8 to znów pod Windowsem się teksty się sypią.
Problem można rozwiązać, ale wymagałoby to dodatkowego kodu. To jest nierealne w aktualnym stanie, bo de facto i tak zostanie to wszystko “zmienione” przy wprowadzeniu lokalizacji.