[Doxygen] Dokumentować czas zacząć! + problem z „include guards”.

Ze względu na to, że jestem w trakcie tworzenia biblioteki która ma zamiar w przyszłości ujrzeć światło dzienne i powiedzieć “hello, world” na ekranie [mam nadzieję] wielu programistów i użytkowników końcowych, pomyślałem o tym, żeby w końcu zająć się napisaniem stosownej dokumentacji do projektu. Przez długi czas w moim kodzie funkcjonowały przeróżne komentarze opisujące mniej lub bardziej dokładnie “co się w danym miejscu dzieje”, ale były to bardziej opisy dla mnie, jako twórcy rozumiejącego cel i działanie poszczególnych elementów, niż dla kogoś, kto miałby w przyszłości korzystać z tego produktu. Pomyślałem więc [w “międzyczasie” zmuszając się do odrzucenia standardowego podejścia w stylu “dlaczego miałbym korzystać z rozwiązań zewnętrznych, skoro sam mogę stworzyć generator dopasowany do moich wymagań?”], że należałoby znaleźć dobre narzędzie pozwalające na stworzenie dokumentacji na podstawie kodu źródłowego w łatwy i w miarę przyjazny sposób.

[C++] Klasy zaprzyjaźnione: "co je twoje, to je moje, a co moje, to nie rusz".

Dzisiaj czytałem nieco o klasach zaprzyjaźnionych w języku C++ [ang. friend classes] i podczas lektury jednego z artykułów przypomniało mi się znane z podstawówki powiedzenie “co je twoje, to je moje, a co moje, to nie rusz”. Przez chwilę patrzyłem na przykładowy kod i nagle wpadł mi do głowy pewien pomysł. Wymyśliłem implementację tego powiedzenia w C++. ;] Oznaczenie klasy jako zaprzyjaźnionej z inną oznacza m. in. to, że wszystkie atrybuty tej pierwszej, niezależnie od klasyfikatora dostępu [public, protected, private] stają się dostępne dla drugiej bez żadnych ograniczeń. Pierwsza klasa “przekazuje” wszystkie informacje o sobie tej drugiej tak, jakby kwalifikatorem dostępu dla wszystkich jej elementów [atrybutów i metod] było słowo kluczowe public. Analogia jest, przynajmniej dla mnie, bardzo wyraźna. ;]

[C++] "std::string" vs. "const std::string&", czyli o przekazywaniu zmiennych słów kilka.

Samodzielna nauka jest w wielu przypadkach bardzo ciekawym doświadczeniem, z co najmniej dwóch powodów:

  • satysfakcja z udanej eksploracji nieznanych dotąd zasobów wiedzy.
  • możliwość samodzielnego wyboru tempa i zakresu informacji opracowywanych podczas jednej "lekcji".
Ma jednak jedną podstawową wadę - nikt poza uczniem nie weryfikuje poprawności przetwarzanych danych, a także ich zrozumienia. Dlatego czasem, pomimo tego, że nierzadko w wielu sprawach potencjalny uczeń ma rację, to i tak trzeba go "wyprostować", wskazać inny, bardziej poprawny, sposób myślenia. Do czego zmierzam? Jak zwykle, chcąc podzielić się z innymi nieco wiedzą, do jednego z moich doświadczeń z przeszłości.
[C++] Wydajność arytmetyki wskaźników.

W tym artykule chciałbym przedyskutować sposoby stosowania i wydajność arytmetyki wskaźników przy poruszaniu się po tablicach. Na wstępie muszę zaznaczyć, że dosyć trudno było mi wybrać tytuł, bo nie wiedziałem jak nazwać ten problem. ;] Ale do rzeczy. Programując jeden z moich projektów zacząłem zastanawiać się nad tym, w jaki sposób można najbardziej optymalnie wykonać operacje na każdym z elementów, tak, aby był jak najmniejszy narzut na dostęp do każdego z nich. Nie mogłem znaleźć w internecie żadnych informacji, w których byłoby napisane jednoznacznie, jaką konstrukcję należy wybrać, zostałem więc zmuszony do samodzielnego przetestowania wszystkich, jakie znałem. ;]