Potrzebowałem w prosty sposób i łatwy sposób logować moment tworzenia i niszczenia obiektów. W najprostszym wypadku wystarczyłoby przeciążyć operator new i delete, ale wtedy logowanie dotyczyłoby tylko obiektów tworzonych na stercie. A ja chce i stos, i stertę ;)
No to wystarczy w konstruktorze i destruktorze umieścić wywołanie funkcji logującej i problem znika. Tylko, że w każdej klasie musimy dodać ten kod, a jak wspomniałem sposób powinien być najprostszy i najłatwiejszy.
Zakończyłem zabawę z kreatorem nowego profilu. Może nie jest on taki rozbudowany, ale na razie do stworzenia profilu potrzebujemy tylko nazwy, hasła i awatara, więcej informacji nie jest potrzebne.
Prawdopodobnie przy pierwszym uruchomieniu profilu pojawi się jeszcze jakieś info albo mini kreator, do utworzenia konta i wyboru sieci z ich skonfigurowaniem.
Jeszcze czeka mnie kilka małych poprawek w klasie zarządzania profilami i można przejść dalej. Choć aktualnie cały istniejący kod jest w ciągłym “ruchu”, więc ciężko powiedzieć co tak naprawdę będę robił i co się zmieni…
Miałem coś napisać o API, ale o nim może innym razem, gdy już będę nad nim pracował.
A póki co, pierwsze widoczne efekty prac daje się już zauważyć ;)
Jak łatwo można się domyślić, jest to okno wyboru profilu i logowania. Pierwsze okno jakie się ukaże na naszym pulpicie po uruchomieniu programu. Oczywiście, zależnie od tego czy będzie istniał jakiś profil, a ustawienia nie zmienią zachowania procesu uruchamiania aplikacji.
Teraz pozostaje zając się kreatorem nowego profilu oraz mniej widoczną stroną aplikacji - modułem menadżera profili.
O tym, co to wtyczka i czym może stać się dla użytkownika programu, można dowiedzieć się na Wikipedii:
Wtyczka (ang. plug-in) to dodatek do istniejącego programu rozszerzający jego możliwości lub automatyzujący żmudne czynności.
Wtyczka może stać się źródłem dodatkowej, dowolnej funkcjonalności, jakiej zabrakło w głównym programie. Oczywiście zdarza się, tak jak w naszym przypadku, że to właśnie wtyczki odpowiadają za całą (lub prawie całą) funkcjonalność programu, a bez nich sam program staje się bezużyteczny.
Nieraz zdarza się, że przechowujemy w kontenerach STL-owych niebanalne obiekty, czy typy nieco bardziej rozbudowane od typów wbudowanych. Praca na takich obiektach i zbiorach z wykorzystaniem algorytmów STL-a może być przyjemna i często nawet lepsza od ręcznego rzeźbienia kodu, choć czasem mogą pojawiać się jakieś pułapki.
Dla przykładu, załóżmy, że mamy vector wypełniony prostymi obiektami o budowie zbliżonej do następującej struktury:
struct MyObj { int foo; int bar; std::string name; }; I chcielibyśmy wyszukać w nim element o nazwie “foo”.
Wypadałoby napisać kilka słów o założeniach i celach projektu oraz obranej ścieżce jego rozwoju. Dlatego poniżej przedstawiam kilka takich podstawowych i zasadniczych elementów jakie przyświecają projektowi.
Jednym z głównych założeń, podwaliną powstania projektu jest cross platformowość. Brakuje na rynku dobrych i rozbudowanych aplikacji tego typu. Multi platformowość zapewnia wspaniały toolkit jakim jest wxWidgets.
Przede wszystkim xime musi być szybki i stabilny, są to podstawowe i priorytetowe cele jakie muszą zostać spełnione.
Nie wszyscy pewnie mają świadomość, że w C++ istnieje możliwość definiowania aliasów dla przestrzeni nazw. Coś jak typedef dla namespace ;)
Mechanizm ten pozwala na przypisanie innej nazwy dla istniejącej już przestrzeni nazw.
Szczególnie użyteczne przy długich nazwach, gdzie pozwala unikać ciągłego wpisywania tych nazw:
namespace my_long_namespace_name { int i; } my_long_namespace_name::i = 5; namespace my = my_long_namespace_name; my::i = 5; lub zagnieżdżonych przestrzeniach:
namespace my_long_namespace_name { namespace my_utils { void f() { // .
Po długim oczekiwaniu nastał ten dzień. Po trudnych próbach i przeszkodach rzucanych pod nogi, przebrnięciu przez długą drogę po skalistych zboczach dotarliśmy do wyznaczonego celu… A raczej początku kolejnej podróży ;)
Bardzo się cieszę, że z wielką radością i z zaszczytem mogę poinformować, że wraz z dzisiejszym dniem oficjalnie startuje projekt o kodowej (i zapewne docelowej) nazwie xime. Jest to projekt nowego komunikatora, a raczej multikomunikatora, w którym większość funkcji będzie dostępna za pośrednictwem wtyczek.
Robiąc małe porządki natrafiłem na kilka schematów i układów zamków szyfrowych i naszła mnie taka mała refleksja dotycząca kwestii bezpieczeństwa. Pomijając tutaj idee i sposoby działania, typowe proste projekty elektronicznych zamków szyfrowych, a raczej ich wykonanie, posiadają pewną zasadniczą wadę związaną z bezpieczeństwem.
Mam tutaj na myśli pakowanie całego układu w jedną obudowę i montaż przed drzwiami chronionego pomieszczenia lub obiektu. To tylko pozorna ochrona. W takim wykonaniu zabezpieczenie to nie jest żadną przeszkodą.
Zaktualizowałem plugin Gadu Radio dla komunikatora Tlen.pl.
Wersja 2.0.0.11 wprowadza małą poprawkę:
zwiększenie bufora używanego przy przetwarzaniu configu; Musiałem zwiększyć bufor z 1KB do 4KB, bo sekcja z kanałami się rozrosła i zajmuje obecnie ponad 1024 znaki, przez co wtyczka doświadczała crashu.
Kochana funkcja GetPrivateProfileSection przy buforze o niewystarczającym rozmiarze zwraca rozmiar tego bufora pomniejszony o 2, co jest trochę kłopotliwe. Lepiej byłoby, gdyby, podobnie jak inne funkcje, zwracała rozmiar potrzebnego bufora, ale rozumiem, że tak nie jest z powodów optymalizacyjnych.