Korrekt in diesem Sinne heisst, dass sich (unter anderem) die g++.exe und die cc1plus.exe in der PATH Umgebungsvariable befinden müssen. Ansonsten meckert bjam diese Programme als “fehlend” an.

Die Einrichtung ist aber wirklich einfach (zumindestens unter Vista und XP):

• Sucht den Pfad zu eurer mingw Installation raus. Ich werden diesen Pfad im Folgenden als $mingw bezeichnen.
• Tipp am Rande: Wenn ihr mit Code::Block arbeitet ist mingw in dem Unterordner “mingw” eurer Code::Blocks Installation zu finden.
• Öffnet die Systemeigenschaften (z.B. über Arbeitsplatz -> Eigenschaften).
• Wählt dort den Punkt “Erweitert” aus.
• Klickt dort auf “Umgebungsvariablen”.
• Wählt bei den Systemvariablen die Variable “Path” aus und hängt die folgende Zeichenkette hinten dran: “$mingw\bin”;”$mingw\libexec\gcc\mingw32\3.4.5″;
• Wichtig: Nehmt die Anführungszeichen um den Eintrag mit und löscht keine Einträge!
• Nun müsst ihr gegebenenfalls noch eine neue Instanz der cmd.exe starten und dann sollte das gcc toolset wirklich funktionieren

Und abschließend nochmal ein Screenshot zur Verdeutlichung:

• Zip Archiv mit odt und pdf Version des Aushangs

Solltet ihr Tipp- oder andere Fehler finden, bitte einen kurzen Hinweis in den Kommentaren vermerken. Nett wäre es auch, wenn ihr mir mitteilt wo / wieviele von den Aushängen ihren Weg in die THS gefunden haben.

• Lambda Funktionen
  Damit wird die ganze <algorithm> Funktionalität der STL drastisch vereinfacht beziehungsweise intuitiver. Auf c.s. notes gibt es eine gute Erklärung was Lambdas eigentlich so sind. In Kurzform: Damit kann man sich z.B. endlich alle möglichen Strukturen, die nur den Operator() implementieren ein für alle mal sparen!
• Das auto Keyword
  Im “jetzigen” Standard ist auto als eigenes Keyword eigentlich komplett sinnfrei. Es bezeichnet lediglich die “normale” Speicherklasse von Variablen. Aber mit C++0x wird daraus eine Art Kurzschreibweise für “bekannte” Typen. Verkürzt gesagt, hat eine Autovariable immer den Typ der Variable, der ihr als erstes zugewiesen wird. Damit kann man sich z.B. bei Iterationen mittels for() eine Menge Tipparbeit sparen:

  std::vector<sometype> v;
  // v sollte natürlich noch mit Werten gefüllt werden,
  // aber für ein Beispiel geht das auch mal so.
  // Ohne auto iterieren
  for (std::vector<sometype>::iterator it = v.begin(); it != v.end(); it++)
  {
      std::cout << *it << std::endl;
  }
  // Mit auto iterieren
  for (auto it = v.begin(); it != v.end(); it++)
  {
      std::cout << *it << std::endl;
      *it = anothertype(); // Fehler, it ist vom Typ sometype
  }

  Plötzlich passt die Iteration also sogar bequem in die beschränkte Breite dieses Blogs. Und natürlich könnte man hier auch mit typedefs arbeiten (sollte man imho auch), dadurch verschiebt sich das eigentliche Problem aber nur.

• nullptr
  Eines der von C geerbten Probleme von C++ ist es, zwischen dem Zahlenwert 0 und einem Nullpointer zu unterscheiden. C++0x führt (hoffentlich) endlich ein explizit für dieses Szenario gedachtes keyword ein: nullptr. Ich kann hierfür leider kein direktes Beispiel geben (ich find einfach keins), aber alleine die Aussicht auf ein Verhalten wie man es auch von Java oder meinetwegen C# kennt ist großartig!

• Aus der Sicht eines Windowsprogrammierers ist es verdammt einfach Linux zu unterstützen! Ein praktisches Tool namens wxconfig kennt die Feinheiten des Linuxsystems auf dem es installiert ist und nimmt es dem Programmierer ab, Linker- und Compileroptionen statisch zu setzen. Bei meinem aktuellen Projekt übergeb ich als einzige Linker Option so zum Beispiel das:

  `wx-config --libs --gl-libs`

  Und schon werden die benötigten Libraries mitgelinkt. In der überaus heterogenen Welt der Linux Distributionen äusserst hilfreich!

• Die RAD Tools sind vorhanden und zumindestens brauchbar. Ich persönlich habe mich für den wxFormBuilder entschieden. Dieser erzeugt eine Basisklasse mit allen Layoutinformationen und Controls und ich muss dann nur noch davon erben und kann dann Events überschreiben. Andererseits muss ich nach jedem Erstellvorgang den Quellcode doch nochmal von Hand anpassen, weil die “relative Pfadangaben” Option vor alle Pfade ein “./..” klatscht. Das entspricht zwar dann dem Layout in der Quellcode Ordnerhierarchie, aber nicht der Ordnerhierarchie des Programms.
• Einige Teile von wxWidgets wirken sehr “offiziell” sind aber nur sehr mäßig unterstützt. In meinem Fall war das wxGlCanvas, also eine “integrierte” OpenGL Zeichenfläche ein Stolperstein. Ich verweise hierbei auf einen Thread von mir im wxWidgets Forum. Für Faule: die “Lösung” meines Problems war am Ende, dass sich zwei (verschieden überladene) Konstruktoren undokumentiert anders Verhalten haben …
• Die wxString Klasse hat irgendwie in Verbindung mit dem gcc Compiler (und auch dem MinGW) einen Klatsch weg. wxString::Format() und wxString(char*, wxConvUTF8) führen teilweise zu äusserst bizarren Fehlern, die erst nach den obigen Methoden auftauchen. Ich hab keine Ahung woran das liegt, vielleicht ist es am Ende ja doch nur ein Fehler auf meiner Seite … Der MSVC++ Compiler frissts aber!

Standard C++ definiert die bekannte main() Funktion.

int main(int argc, char** argv)

Die Windows spezifische Version schaut so aus:

int WINAPI WinMain(HINSTANCE hInstance,
                   HINSTANCE hPrevInstance,
                   LPSTR lpCmdLine,
                   int nCmdShow)

Ich werde hier nicht weiter auf die Unterschiede bezüglich hPrevInstance und hInstance eingehen, da weiß Google besser bescheid. Stattdessen gehe ich auf lpCmdLine und nCmdShow ein.

Wer sich an Dinge wie die STL gewöhnt, vermutet immer gerne mal wieder, dass Dinge überall gleich funktionieren. Sollten sie zwar auch, hier tun sie es aber nicht!

Ich ging in meiner Naivität davon aus, dass nCmdShow die Entsprechung für argc und lpCmdLine die Entsprechung von argv wäre. NEIN! lpCmdLine schmeisst einen Teil der Vorteile von argv weg: Es fügt die Kommandozeilen Parameter in einem einzigen String zusammen. Während argv also eher wie ein Array aus char* zu handhaben ist, wobei der Index 0 dem Pfad zum Programm entspricht, ist lpCmdLine ein einziger String aller Parameter ohne den Pfad zum Programm.

Gegenübergestellt schaut das so aus:

Kommandozeile: /usr/bin/foo -key value -foo "foo bar"
lpCmdLine: "-key value -foo \"foo bar\""
argv[0]: "/usr/bin/foo"
argv[1]: "-key"
argv[2]: "value"
argv[3]: "-foo"
argv[4]: "foo bar"

if (pointer)
{
    delete pointer;
    pointer = NULL;
}

Ein einfaches delete und auf NULL setzen tuts auch

Wer noch nie was von Scott Meyers gehört hat und sich trotzdem als “erfahren” in der Programmierung mit C++ bezeichnet, leidet mit sehr großer Wahrscheinlichkeit an Selbstüberschätzung. “Effective STL” ist eine Art indirekter Nachfolger von “Effective C++”.  Und es ist meiner Meinung nach auch für Anfänger relativ gut zu verstehen. Meyers geht bei “Effective STL” zunächst davon aus, dass der Leser bisher größtenteils den Container Anteil der STL verwendet hat, ohne sich tiefergehend mit diesen zu beschäftigen.

Das Buch ist sehr übersichtlich gegliedert und umfasst die folgenden Sektionen:

1. Containers
2. vector and string
3. Associative Containers
4. Iterators
5. Algorithms
6. Functors, Functor Classes, Functions, etc.
7. Programming with the STL

Es sollte also für jeden was dabei sein.

So wie einige Leute schlechten Code in “wtfs per minute” messen, messe ich Fachbücher an “ahas per minute”. Nun kommt Meyer diese Art der “Messung” ohne Frage entgegen, immerhin gliedert er seine Bücher in einzelne Tipps, die zwar teilweise untereinander verweisen, aber trotzdem alle für sich selbst stehen können. In “Effective STL” bietet Meyers 50 dieser Tipps.

Wie immer sind diese teilweise sehr einfach zu verstehen, aber man ist trotzdem dankbar für die gute Argumentation seitens Meyers. Er beleuchtet auch triviale Sachverhalte so ausführlich, dass sie einem einfach im Kopf bleiben müssen … Wer hört, dass die Zuweisung von Container über z.B. vector.assign() sinnvoller ist als über Schleifen, wird das möglicherweise wieder vergessen. Wem dann aber noch im Detail erklärt wird, was sich mit copy() und insert() so ohne weiteres anstellen lässt, der begreift nicht nur was assign() macht, sondern wir die STL funktioniert.

Und das ist es im wesentlichen was Meyers macht: er erklärt die “vorgesehene” Nutzung der STL. Die meisten Leute sind so froh über grundlegende Container wie vector<>, dass sie vergessen zu gucken was diese ausser der dynamischen Größe nochmal mehr können als Arrays. Und genau hier setzt Meyers an!

Für jemanden der sich mit der STL schon eingehend beschäftigt hat, bietet das Buch somit nur die Hälfte. Es untermauert das eigene Wissen sinvoll, ist aber gemessen an “ahas per minute” nicht unbedingt ein Spitzenreiter. Wenn man jedoch z.B. Willi heißt und grundsätzlich erstmal brachiale Ansätze wählt, wird man aus dem Staunen kaum mehr herauskommen

Effective STL: 50 Specific Ways to Improve the Use of the Standard Template Library (Addison-Wesley Professional Computing)

Das Zauberwort heißt std::tolower in Kombination mit std::transform. std::transform wird genutzt, um einen Bereich (begrenzt durch zwei Iteratoren) gleichzeitig zu kopieren und mit einer Funktion umzuwandeln. Die Signatur von std::transform sieht in etwa so aus:

OutputIterator transform(InputIterator first,
                         InputIterator last,
                         OutputIterator result,
                         UnaryOperation op);

Dabei ist es kein Problem, wenn first und result identisch sind. op bezeichnet die Funktion, die wir für jedes zu transformierende Objekt aufrufen wollen.

Mit diesem Rüstzeug können wir einen beliebigen String “verkleinern”:

// Converting the string to lowercase
std::string string("I aM WriTten In MixED cASe!");
std::transform(string.begin(), string.end(), string.begin(), std::tolower);

Edit am 7.9.2008:

Da hab ich doch glatt vergessen die header mit “bekanntzugeben”. Also hier:

#include <string> // std::string
#include <algorithm> // std::transform
#include <cctype> // std::tolower

0xCC is uninitialised stack (local variables).
0xCD is uninitialised heap (new).
0xDD is freed heap memory.
0xFD is put before and after a block, to check for overruns.

Es steckt also doch ein tieferer Sinn hinter den Werten … Gut, dass zu wissen.

Bjarne Stroustrup – Erfinder und Entwickler der Programmiersprache C++

“Ich habe mir immer gewünscht, dass mein Computer so leicht zu bedienen ist wie mein Telefon; mein Wunsch ging in Erfüllung: mein Telefon kann ich jetzt auch nicht mehr bedienen.” – um 1990, nach dem Versuch, ein Multifunktions-Telefon zu benutzen;

“C macht es einfach, sich selbst ins Bein zu Schießen; C++ erschwert es, aber wenn es dir gelingt, bläst es dir das ganze Bein weg” – um 1986

Linus Torvalds – Begründer von Linux

“Nur Weicheier benutzen Datensicherungen auf Band: richtige Männer laden ihren wichtigen Kram einfach auf einen FTP und lassen diesen vom Rest der Welt spiegeln.” – Posting im Usenet, 1996

“Das war mein Leben: Ich aß. Ich schlief. Vielleicht ging ich zur Uni. Ich programmierte. Ich las eine Menge E-Mails. Mir war klar, dass manche meiner Freunde mehr Sex hatten, aber das war okay. Offen gesagt, die meisten meiner Freunde waren auch Loser.” – aus der Autobiographie “Just for Fun. Wie ein Freak die Computerwelt revolutionierte.” Sehr zu empfehlen

Insbesonders das Letzte finde ich herrlich passend zur “Freak / Nerd” Problematik. Der Mann hat schlichtweg recht *g*

string[] strings = {"Foo", "Bar", "Foobar"};
foreach (string s in strings)
{
    Console.WriteLine(s);
}

Der obige Quellcode in C# würde nun einfach das Array strings in der Konsole ausgeben. Wenn es nun an C++ geht, findet man bei vielen Leuten ungefähr den folgenden Code:

std::string strings[3] = {"Foo", "Bar", "Foobar"};
for (int i = 0; i < 3; i++)
{
    std::cout << strings[i] << std::endl;
}

Und jo, wenn man das auf die gezeigte Art und Weise macht, dann muss man leider weiterhin per Indexoperator auf die einzelnen Strings zugreifen. Aber mal im Ernst, Arrays sind doch sehr C

C++ kommt im Verbund mit der STL und die STL bietet einen Ausweg aus diesem Dilemma: Iteratoren. Per Iterator lässt sich eine foreach Schleife in C++ ungefähr so darstellen:

typedef std::vector<std::string> stringvector;
 
stringvector strings;
strings.push_back("Foo");
strings.push_back("Bar");
strings.push_back("Foobar");
 
for (stringvector::iterator it = strings.begin(); it != strings.end(); it++)
{
    std::cout << *it << std::endl;
}

Da es sich bei std::vector nicht um ein Sprachelement von C++ handelt, müssen wir ihn in diesem Fall mit der push_back Methode füllen, aber das ist sowieso realitätsnaher

Spannender ist die for Schleife. Anstatt wie gewohnt einen integer zum Zählen zu benutzen, machen wir uns das Verhalten von Iteratoren zunutze. Diese lassen sich wie integer vergleichen und inkrementieren bzw. dekrementieren. Wir initialisieren unseren Iterator mit dem ersten Element unseres Vektors, prüfen in der Bedinung ob wir schon am Ende angelangt sind und inkrementieren den Iterator nach jedem Durchlauf.

Wichtig ist aber, dass man den Iterator, wenn man auf seinen Inhalt zugreifen möchte, mit dem * oder -> Operator dereferenzieren muss.

int operator [] (const std::string& s)
{
    return (this->GetSomeInt(s));
}

In C# ist der Syntax ein wenig anders:

public int this[string s]
{
     get { return (GetSomeInt(s); }
}

Soo, von nun an muss ich nur noch ins Blog gucken wenn ich den “C# Weg” mal wieder vergessen haben sollte

1. Boost.Signals oder Libsigc++
   Wird primär ein Vergleich werden. Mal schauen was mir am Ende besser zusagt. Wäre die Boost Variante “Header Only”, wüsste ich schon was ich nehmen würde. Das würde die Weitergabe so herrlich viel einfacher machen.
2. Boost.Random statt GX::Rand()
   Hehe, ich bin einfach faul ^^ Die Boost Variante schlägt meine Implementierung um Längen.
3. Boost.Python statt Lua
   Mit Python habe ich mich mittlerweile einfach mehr auseinander gesetzt. Abgesehen davon, dass ich den Lua Syntax einfach nicht mag.

Ich tippe mal, dass sich das auch in starkem Umfang auf die GxLib auswirken wird. Aber erstmal geh ich spielen =)

Für “Nichttechies / NichtCppler” (ja, das ist definitiv ein Unterschied) ist dieser Eintrag aber dennoch sehr spannend:
The wisdom of seventh graders: Designing an elective course
Für alle die kein Bock auf die Übersetzung haben in etwa: “Die Weisheit von Siebtklässlern: Designe ein Wahlfach”.

Nehmen wir an wir haben folgende Cfg Date. Relativ zur ausführenden Datei findet sie sich in data/config.cfg

[Sektion]
eins=wert
zwei=trakaka
drei=dooof
vier=lala
fünf=burp
sechs=lal

Aus dieser möchten wir nun den Wert “drei” der Kategorie “Sektion” auslesen. Mit der GxLib ganz einfach.

int main (void)
{
 GX::CfgFile cfg("dataconfig.cfg");
 cfg.parse();
 std::string a = cfg["Sektion"]["drei"];
 
 return (0);
}

Nun fehlt nur noch so unwichtiger Kleinkram wie vernünftiges Errorhandling, die Möglichkeit durch Sektionen oder Einträge zu iterieren, eine Anbindung an Gx::Root, Bugbusting … So gut wie fertig also *g* Aber die Basisfunktionalität steht und in der Handhabung wird sich nix ändern.