Ekstremalne programowanie w C++ (i nie tylko)

Jak działa polimorfizm wie każdy programista języka C++ jest to przecież najpopularniejsza cech programowania obiektowego. Za pomocą funkcji wirtualnych, klas abstrakcyjnych jesteśmy w stanie tworzyć kod ogólny, bazując jedynie na interfejsach, zrzucając jednocześnie sposób rozwiązania na klasy pochodne dostarczające implementację. Wszystko pięknie ładnie i elastycznie. Niestety funkcje wirtualne są najzwyczajniej w świecie wolne. Jak wiadomo są miejsca w każdym dużym projekcie które wymagają minimalizacji opóźnień. Czy w tych miejscach należy zatem rezygnować z polimorfizmu i oferowanej przez niego elastyczności na rzecz maksymalizacji czasu działania kodu? Na szczęście są sposoby na obejście tego problemu, z pomocą przychodzą nam jak zwykle szablony. Zacznijmy od zaprezentowania szablonu który w pozwala na zdefiniowanie typu na podstawie wartości (więcej szczegółów na ten temat można znaleźć w Nowoczesne projektowanie w C++. Uogólnione implementacje wzorców projektowych ). te

Ten wpis rozpoczyna cykl dotyczący metaprogramowania, ilość oraz częstotliwość publikacji kolejnych części pozostaje nieustalona. Poniżej zaprezentowane zostanie absolutny elementarz, czyli wyznaczanie dowolnego elementów wyrazu ciągu Fibonacciego w czasie kompilacji. #include <iostream> template<unsigned int N> struct Fib {   static const unsigned int el = Fib<N-1>::el + Fib<N-2>::el; }; template<> struct Fib<0> {   static const unsigned int el = 0; }; template<> struct Fib<1> {   static const unsigned int el = 1; }; int main(void) {   const unsigned int N = 5;   std::cout << "fib( " << N << " ) = " << Fib<N>::el << std::endl;   return 0; } Tych parę linijek zmusza do wyliczenia 5 elementu ciągu Fibonacciego kompilator, co oznacza że jedynymi instrukcjami jakie zostaną wykonane przez nasz program po sko

Jako programista klasycznego C przyszło mi wielokrotnie ścierać się z makrami. Makro to zestaw instrukcji umieszczanych w kodzie są jednak interpretowane nie przez kompilator ale przez preprocesor. Preprocesor jest „pomocnikiem” kompilatora, zajmuje się on np. wstawianiem treści plików nagłówkowych do plików z kodem za pomocą instrukcji #include. Preprocesor należy rozumieć jako prymitywny edytor tekstu dokonujący „korekcji” plików z kodem źródłowym przed rozpoczęciem ich przetwarzania przez kompilator. Jakie są zalety wykorzystywania tych rozwiązań w kodzie? Tak naprawdę w języku C w czasach przed wprowadzeniem słowa kluczowego inline umożliwiały wstawianie kodu we wskazane miejsce. Należy bowiem pamiętać że każdorazowe wstawienie makroinstrukcji powoduje ingerencję w kod źródłowy (innymi słowy we wskazanym miejscu zostanie wstawiony stosowny fragment kodu). Łatwo obserwowalnym efektem częstego wykorzystywania makr w plikach z kodem jest rozrost pliku binarnego oraz jego szybsze d

Czym jest zintegrowane środowisko programistyczne(IDE) nie trzeba tłumaczyć. Do najpopularniejszych należą Visual Studio, Eclipse, NetBeans, QTCreator, Borland Developer Studio, Xcode. Posiadają wiele przydatnych narzędzi do refaktoringu kodu, podpowiadają składnie, indeksują symbole w obrębie projektu, integrują się z systemem kontroli wersji i posiadają tysiące funkcji „ułatwiających” codzienną pracę. Skoro są takie cudowne to czy można im coś zarzucić? Moja odpowiedź brzmi TAK. A jest to przede wszystkim konfiguracja projektu do pracy z zewnętrznymi niestandardowymi bibliotekami i sposób budowania. W większości wymienionych środowisk nie jest generowany automatycznie plik makefile, ustawienia sposobu budowy projektu i linkowania zaszyte są gdzieś po zakładkach, i opcjach konfiguracyjnych. Jestem jednocześnie świadom że każde z tych środowisk pozwala na wczytanie własnego makefila i na jego podstawie potrafi utworzyć, zindeksować projekt, tym nie mniej nie jest to opcja

Zasadniczo iterowanie po elementach tablicy/vectora/listy itp. nie jest niczym nowym, interesującym ani pasjonującym, ot szara codzienność. Przyjrzyjmy się zatem jak robimy to najczęściej: class Image { public:   Image();   void rotate(float angle);   void display();   void* serialize(); }; class ShowImage { public:   void operator()(Image image)   {     image.display();   } }; //... std::vector<Image> imageCollection(10); for(int i=0; i<imageCollection.size(); ++i) {   imageCollection[i].display(); } for( std::vector<Image>::iterator                          currentImage = imageCollection.begin();                         currentImage < imageCollection.end();                         ++currentImage ) {   currentImage->display(); } std::for_each(imageCollection.begin(), imageCollection.end(),               ShowImage()); Dla naszych potrzeb stworzyliśmy sp

Jakiś czas temu spotkałem się z sytuacją gdy jeden z moich kolegów zaimplementował klasę która w zamiarze maiła być singletonem. Sprawa wydawała by się prosta prywatny //----------------------------------------------------- singleton.h @interface Singleton    +(Singleton*) instance @end //----------------------------------------------------- //----------------------------------------------------- singleton.m @implementation Singleton static Singleton* instance; +(Singleton*) instance {    if(!instance)    {      instance = [[Singleton alloc] init];    }    return instance; } +(id) init {   self = [super init];   return self; } @end //----------------------------------------------------- Problem w tym że przy takiej implementacji mam do czynienia z umownym singletonem gdyż nic nie stoi na przeszkodzie aby w kodzie klienckim napisać id fake_singleton = [[Singleton alloc] init]; Przez co istnieje możliwość utworzenia wielu instancji klasy Singleton. Ponieważ do self przypisywa

Od jakiegoś czasu przymierzałem się do stworzenia własnego bloga dotyczącego szeroko rozumianego programowania, czego efektem jest niniejszy blog. Poruszane tematy będą dotyczyć programowania ze szczególnym uwzględnieniem języka C++, wzorców projektowych, życia z pingwinem, oraz okazjonalnie platformy Mac OS X/iOs z wykorzystaniem objective-c. Część wpisów będzie miała charakter czysto techniczny, część z nich będzie formą osobistych rozważań na tematy około informatyczne. Kilka słów o mnie: Jestem stosunkowo młodym developerem, w swojej zawodowej karierze miałem już jednak okazję zajmować się implementacją algorytmów do przetwarzania obrazów przemysłowych z wykorzystaniem platformy .Net, C, C++, CUDA, implementacją GUI'ca na systemy wbudowane (telefony nie będące smrtfonami) a obecnie rozpoczynam swoją przygodę z Mac OS X'em, iOs'em oraz objective-c. Coś wiem, coś słyszałem, coś implementowałem i na wiele tematów mam własne zdanie z którym można się zgadzać lub nie.