Dlaczego nie warto używać Dev-C++

24.01.2010 @ 19:27:52 by Rafał Kozik | C++ programowanie narzędzia

Często wracającym tematem na warsztacie są mniejsze lub większe problemy z działaniem / używaniem Dev-C++. Rozpoczyna się wtedy święta wojna zwolenników i przeciwników tego narzędzia. Jest to sytuacja o tyle dziwna, że o ile typowy flame w stylu Windows vs Linux lub DirectX vs OpenGL ma jeszcze jakiś sens i można podać sensowne argumenty dla każdej ze stron, o tyle bronienie Dev-C++ jest poważnym błędem i powinno być karalne.

Tak, Dev-C++ jest zły. Nie mówię, że taki był zawsze -- sam kiedyś z niego korzystałem, tak samo jak wiele innych osób, które są teraz jego przeciwnikami. Co sprawia, że to narzędzie wywołuje aż takie skrajne emocje?

  • Ostatnia wersja Dev-C++ to 4.9.9.2 -- jest to wersja, której sam używałem lata temu. Została ona udostępniona 22 lutego 2005 roku! Już za miesiąc będzie mogła świętować swoje piąte urodziny!
  • W pakiecie zawarty jest MinGW oparty o GCC 3.4.2 -- wersję z września 2004 roku. Dlaczego to ma znaczenie? Dużo się w tym czasie zmieniło i dlaczego miałby ktoś korzystać z tak starych wersji?
  • W porównaniu do dostępnych teraz narzędzi jest bardzo ubogi
  • Ma sporo wad, choćby potrzeba ręcznego uruchomienia kompilacji przed uruchomieniem. Jest to w sprzeczności z jedną z podstawowych zasad, które warto stosować w pracy -- jeżeli da się coś łatwo zautomatyzować, zrób to.
  • Nie ma sensownego debuggera -- przed tym kto nie wie jak duże ma to znaczenie jeszcze długa droga ;)
  • Twórcy różnych bibliotek go nie wspierają i nie ma gwarancji, że kod się pod nim skompiluje.

Problem jest o tyle duży, że dużo początkujących programistów trafia na Dev-C++ jako polecane środowisko w tutorialu bądź książce. Ostatnio spotkałem się też z sytuacją, gdzie w jednym z Wrocławskich liceów używają tego archaicznego narzędzia.

Jeżeli dla kogoś jedynym powodem zostania przy Dev-C++ jest to, że go już poznał, to czas, żeby poznać coś nowego. To będzie musiało i tak prędzej czy później nastąpić, skoro nie jest od lat rozwijany. Zawsze można spróbować Visual C++ Express, Eclipse, Code::Blocks (na stronie jest stara wersja, aktualną można znaleźć tutaj) albo NetBeans.

comments komentarze (10)

Dwa nowe projekty

07.08.2009 @ 11:38:24 by Rafał Kozik | C# C++ programowanie

Powoli pracuję teraz nad dwoma projektami, o których jeszcze nie było wspominane. Czas najwyższy to zmienić.

GraphIt

GraphIt (zalecana wymowa 'po naszemu' to po prostu grafit ;)) jest biblioteką dla .NET wspierającą rysowanie różnego rodzaju grafów i diagramów. Będzie stanowiła część mojej pracy magisterskiej i docelowo będzie udostępniona na licencji LGPL. Z powodu kilku problemów technicznych powstaje wolniej niż się spodziewałem, ale powinno się to już zmienić. Mam nadzieję, że w przyszły weekend będę mógł pokazać screeny z jakiegoś prostego użycia.

Wombat Lite

Jestem w trakcie okrajania Wombata, żeby stał się trochę lżejszy i łatwiejszy w użyciu. Trochę rzeczy w oryginalnym projekcie było zrobionych nie do końca dobrze, brakowało też m.in. obsługi dźwięku, którą trzeba w końcu dodać. Przy okazji pracuję nad większym odseparowaniem rzeczy związanych z konkretnym systemem operacyjnym i renderer jest przenoszony na OpenGL. Biblioteka wciąż będzie zamknięta, ale możliwe, że niedługo pojawią się jakieś małe gierki oparte na tej bibliotece (ale za wcześnie jeszcze na szczegóły).

comments komentarze (1)

Radix sort

01.05.2009 @ 01:50:08 by Rafał Kozik | programowanie C++

Dawno, dawno temu na slashdot pojawił się wpis Sort Linked Lists 10X Faster Than MergeSort. Okazało się, że twórca algorytmu wykazał się brakiem wiedzy i zaproponował algorytm Radix Sort.

Dzisiaj sam zaimplementowałem ten algorytm (okazało się to prostsze niż się spodziewałem) chcąc sprawdzić jak wypada w porównaniu do qsort z cstdlib i sort z STL.

Zrobiłem testy losując sporą ilość intów, a następnie sortując je każdym z algorytmów. Na koniec sprawdzam czy wynik działania wszystkich algorytmów jest taki sam. Wyniki okazały się zaskakujące -- nie spodziewałem się aż tak dużych różnic czasu. Wyniki poniżej.

comments ciąg dalszy i komentarze (0)

Wynalazek zwany PIMPL

06.04.2009 @ 23:04:34 by Rafał Kozik | programowanie C++

Pisząc biblioteki w C++ często można natrafić na problem wytworzenia wystarczająco dobrej enkapsulacji. Definicje klas, znajdujące się w plikach nagłówkowych, często pokazują za wiele: wszystkie prywatne pola i metody, które moglibyśmy chcieć ukryć. Dodatkowym problemem jest to, że praktycznie każda zmiana w implementacji wymaga zmiany definicji klasy, a to często przekłada się na konieczność ponownej kompilacji całego projektu.

Okazuje się, że istnieje bardzo proste rozwiązanie tego problemu -- PIMPL (private implementation):

// plik object.h

class ObjectImpl;

class Object
{
    ObjectImpl* impl;
public:
    Object();
    ~Object();

    int SampleMethod(int x);
};

// plik object.cpp

class ObjectImpl
{
    // Właściwa implementacja
};

Object::Object()
{
    impl = new ObjectImpl();
}

Object::~Object()
{
    delete impl;
}

int Object::SampleMethod(int x)
{
    return impl->SampleMethod(x);
}

Oczywiście wypdałoby jeszcze dopisać konstruktor kopiujący i operator przypisania jeśli to konieczne.

Dodatkowo, można zmienić całkowicie implementację, a dla użytkowników klasy wszystko będzie wyglądać dokładnie tak samo. Jako lekturę uzupełniającą polecam to i stary wątek na forum gamedev.pl.

comments komentarze (1)