Przejdź do głównej zawartości

Posty

Wyświetlanie postów z listopad, 2012

Dlaczego nie lubię zintegrowanych środowisk programistycznych?

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

C++11 Iterowanie

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

iOS – singleton

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

Pierwszy wpis (init commit)

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.