Struktura katalogów w projekcie

Czasami istnieje potrzeba pisania jednego projektu w różnych środowiskach programistycznych, tym bardziej jeśli korzystamy z systemu kontroli wersji (np. SVN,  GIT) i chcemy skompilować projekt z założenia multiplatformowy na innym systemie operacyjnym. W takim przypadku fajnie by było, aby projekt miał strukturę katalogów niezależną od IDE, ale jak powinna ona wyglądać? Według mnie tak:

  • include
  • src
  • workdir
  • projects
  • libs

Katalog include powinien zawierać tylko pliki nagłówkowe, które będą dołączane w innych projektach. Tak naprawdę jest on tutaj tylko ze względu na projekt biblioteki (np. lib, dll, itp.), więc w przypadku kompilacji do pliku wykonywalnego, można ten katalog pominąć, wtedy wszystkie pliki nagłówkowe powinny znaleźć się w katalogu src. Katalog src jest przeznaczony tylko dla plików źródłowych bieżącego projektu, które mogą być uporządkowane w różnych podkatalogach. W workdir powinna się znaleźć cała struktura katalogów docelowego programu, czyli wszystkie pliki i katalogi, które będą dostarczane ze skompilowanym plikiem wykonywalnym. Katalog libs służy do przechowywania wszystkich dołączanych bibliotek używanych w aplikacji. Dla każdej z nich powinien znaleźć się odpowiedni katalog a w nim jeszcze dwa – include i lib. Ostatnim katalogiem jest projects, który jest przeznaczony do przechowywania plików projektów dla każdego IDE (oczywiście każdy w osobnym katalogu).

Taka struktura jest przejrzysta i niezależna od stosowanego IDE. Zresztą nie jest to mój pomysł, ponieważ jest on od dawna stosowany w środowiskach linuksowych, ale w nieco innej postaci. Kluczowe jest po prostu trzymanie plików źródłowych w jednym katalogu niezależnym od stosowanego środowiska.

Problem z kompilacją x64 na Win7 RC

Dzisiaj postanowiłem spróbować skompilować coś pod platformę 64-bitową. Jako że dysponuję teraz już odpowiednim sprzętem, systemem, więc nic nie stało na przeszkodzie aby to uczynić. Ze znalezionych w internecie informacji dowiedziałem się tyle, że wystarczy przestawić docelową platformę z Win32 na x64 i już można przystąpić do próby kompilacji.Przed poprawką

Niestety tu pojawił się problem, ponieważ jedynymi dostępnym platformami oprócz Win32 są platformy ARM. Po kolejnym skorzystaniu z wyszukiwarki Google dowiedziałem się, że winę za to ponosi nieodpowiednia kolejność instalacji Windows SDK 7, Visual Studio oraz braku odpowiedniego dla niego Service Packa. Poprawna kolejność instalacji jest następująca:

  1. Visual Studio 2008
  2. Service Pack 1 dla Visual Studio 2008
  3. Windows SDK 7

Oczywiście nie miałem ochoty robić reinstalacji VS i WSDK, dlatego poszukałem innego rozwiązania. Oto ono:

  1. Deinstalacja “Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x64” oraz “Microsoft Visual C++ Compilers 2008 Standard Edition – enu – x86”
  2. Naprawa instalacji Visual Studio (Przez funkcję Repair)
  3. Instalacja Service Packa

Należy zaznaczyć, że użycie funkcji Repair na instalacji WSDK7 usunie tę poprawkę.

Po poprawce

Tutaj znajduje się oryginalna stronka z opisem naprawy.

Podstawy programowania

W czwartek 2 października odbyły się pierwsze zajęcia laboratoryjne z Podstaw Programowania na Politechnice Wrocławskiej. Językiem programowania na zajęciach jest Java. Nie ma w niej wskaźników, dlatego dla wielu osób jest dużo łatwiejsza niż C++. Ja myślę, że może być to ciekawe doświadczenie i przydatna umiejętność, bo jak wiadomo, najlepiej znać wiele języków.

Największym moim zaskoczeniem na zajęciach okazało się “IDE”, ponieważ ciężko mi nazwać BlueJ środowiskiem programistycznym. Jest to raczej zabawka dla początkujących, która pokazuje w jaki sposób działają funkcje, lecz niestety z poważnym programowaniem ma niewiele wspólnego.  Na stanowisku znalazłem również środowisko Eclipse, więc pomimo, że jeszcze go nie znam, jest nadzieja na coś lepszego.

Problemy z plikami afxres.h oraz winres.h w Visual C++ EE 2008

Mała porada dla tych, którzy chcą otworzyć stare projekty, które zawierają pliki *.rc.
Przy próbie kompilacji takich projektów, może wyskoczyć błąd, który oznajmia, że nie mamy plików podanych w tytule.

Rozwiązanie jest proste, wystarczy nazwę tego pliku podmienić na windows.h. Dzięki temu można korzystać z zasobów ładowanych do pliku *.exe. (Sprawdzałem tylko na prostym projekcie z książki Programowanie w DirectX Masona McCuskey’a).

W Visualu C++ EE, zablokowana jest możliwość otwierania plików *.rc, jednak nie tak do końca, albowiem wystarczy kliknąć na takim pliku prawym przyciskiem myszy, a następnie wybrać Open with… i w oknie wybrać Source Code (Text) Editor. Według mnie zawsze jest to jakieś rozwiązanie.
EDIT: wystarczy kliknąć na takim pliku prawym przyciskiem myszy i opcję View Code. Thx Tarains.

Spotkałem się również z takim problemem, jak brak zdefiniowanej stałej IDC_STATIC (używanej do tworzenia szablonów okien dialogowych).
Kod błędu:
error RC2104 : undefined keyword or key name: IDC_STATIC

W takim przypadku należy do pliku resources.h dodać następujący kod:

#ifdef IDC_STATIC
#undef IDC_STATIC
#endif
#define IDC_STATIC (-1)

Visual Studio 2008 Express Edition i inne…

Tak, wreszcie wyszła długo oczekiwana wersja release najlepszego, darmowego IDE firmy Microsoft: Visual Studio 2008 Express Edition. Na stronie Microsoft’u są dostępne poszczególne wersje do różnych języków, zachęcam do odwiedzenia witryny: http://www.microsoft.com/express/default.asp. Wraz ze środowiskiem ukazał się silnik graficzny (chyba to właściwa nazwa) o nazwie Dark GDK. Jak można się dowiedzieć z kodów przykładowych, korzystanie z niego jest dziecinnie proste, więcej informacji tu: http://gdk.thegamecreators.com/.

Sam aktualnie ściągam obraz płyty na której znajdują się wszystkie wersje IDE, następnie Dark GDK by przekonać się co to dokładnie jest.