Aber sehr überrascht war ich dann davon, dass zwei der größten Mankos der älteren Visual Studio Versionen immernoch vorhanden waren:

• Der “Add Assembly Reference” Dialog (für.Net Projekte) ist immernoch unglaublich langsam, nicht durchsuchbar und dadurch vollkommen unübersichtlich.
• Document Tabs lassen es stark an Anpassungsmöglichkeiten vermissen. Gerade wenn man Dateien mit identischen Namen in verschiedenen Projekten hat, ist das Chaos vorprogrammiert.

Beide Probleme bekommt man wunderbar mit den Visual Studio 2010 Pro Power Tools in den Griff. Übrigens nicht mit den “Visual Studio 2010 – Power Tools” zu verwechseln, das sind Kommandozeilentools … Wer sich auch immer bei Microsoft um die Namensgebung kümmert macht schon länger keinen guten Job! Die Umbenennung der Visual Studio Versionen hat mich eigentlich schon genug Nerven gekostet!

Aber back to Topic: Der neue Add Assembly Reference Dialog ist großartig!

Endlich durchsuchbar, Aufteilung in Core Assemblies und Extensions! Mehr wollte ich ja garnicht.

Und die Document Tabs sind nun wirklich unglaublich flexibel. Für eine komplette Übersicht verweise ich mal auf das Visual Studio Blog, mir persönlich reichen aber schon die folgenden Möglichkeiten:

• “Pinnbare” Tabs. Wer regelmäßig zwischen > 15 Dokumenten springt wird es schätzen, die wenigen wirklich wichtigen seperat auszeichnen zu können.
• Projektabhängige Tabfarben. Endlich keine unendliche Verwirrung mehr bei gleichen Dateinamen.

So schaut das ganze dann bei mir aus:

Jeder der sich für fit genug hielt, konnte eine sogenannte Befreiungsaufgabe schreiben: Tetris =) Und zwar in FreePascal. Also mal ganz was Neues, auch für mich. Mein Zeitplan sah dann in etwa so aus:

• Freitag: FreePascal und sonstige Tools einrichten, bisschen mit FreePascal vertraut machen
• Samstag: Ein Framework für Sachen wie Gamestates und Timing auf die Beine stellen
• Sonntag: Tetris!

Klappte ganz gut, wenn man von diversen IDE Bugs absieht. FreePascal stürzt bei mir mittlerweile kommentarlos ab, sobald ich auch nur versuche irgendeine Datei zu öffnen … Aber ich hab dann wunderbar mit Lazarus weiterarbeiten können.

Allgemein war die Aufgabe schwieriger, als einem zunächst schien. So Sachen wie Blockrotation haben mich dann doch noch an den Rand des Wahnsinns getrieben, bis ich es einfach irgendwann aufgegeben habe, dafür einen allgemeingültigen Algorithmus zu suchen …

Die Anmeldezahlen zur Abnahme waren dann auch dementsprechend. Irgendwann Samstag waren es wohl noch um die 40, Sonntag Abend dann noch ca. 20, Montag (also heute) Morgen waren es noch 9 und bei der Abnahme waren wir dann zu viert …

Und so schaut meine Lösung aus:

Wer mag kann sich das Ganze auch runterladen, aber wirklich gut spielen kann man das nicht. Zumindestens nicht, wenn man unter “spielen” auch “Spaß haben” versteht.

• Windows: FreePaTris.exe
• Linux: FreePaTris

Wer Interesse am Quellcode hat, der ist unter folgender URL öffentlich einsehbar:

• svn://svn.gurxite.de/FreePaTris/trunk

Update:

So, nun auch mit Linux Version. Die flackert auch nicht so nervig

// Yeah, händisch iterieren und zufügen!
foreach (SomeEnum val in Enum.GetValues(typeof(SomeEnum)))
{
	myComboBox.Items.Add(val);
}

 // Whoops, was macht denn die DataSource Eigenschaft ;)
myComboBox.DataSource = Enum.GetValues(typeof(SomeEnum));

Leider kann man die DataSource Eigenschaft nicht schon im Designer mit beliebigen Ausdrücken versehen, die Zuweisung muss also im Quellcode erfolgen.

Aber ungefähr ein knappes Jahr zu spät habe auch ich gemerkt, wie man die Ladezeiten dramatisch reduzieren kann: Man schaltet den Low Bandwith (loband) Modus ein. Im Vergleich schaut das dann so aus:

Als Referenz nochmal die Seite als Link in beiden Versionen:

• “Normale” Version
• “Low Bandwith” Version

Herrlich! Erinnert in dieser Aufmachung ziemlich an JavaDoc oder Doxygen, für mich ein eindeutiger Vorteil. Einen Haken hat die Sache dann aber doch: Die loband Seite scheint ohne Suchfeld zu kommen.

Nicht in diese Kategorie fällt die fehlende Buildkonfiguration.

Die scheint zwar auch zu fehlen, ist aber nur versteckt. Ich habe hier gerade die englische Version vom Visual Studio, das Vorgehen bei der deutschen Version ist aber naheliegenderweise ähnlich:

• “Tools” Menü öffnen
• “Options” Eintrag auswählen
• Im Optionsdialog ein Häkchen bei “Show all settings” setzen
• Unter “Projects and Solutions -> General” einen Haken bei der “Show advanced build configurations” setzen

Einfach weil ich mich mit meinem jetzigen Stand eigentlich ganz wohl fühle, es gibt keine “Ecke” mehr bei der ich Angst habe etwas zu verpassen.

Für wirklich zeitkritische oder lowlevel Sachen greife ich zu C++, alles was irgendwie schön mit einer Oberfläche daherkommen oder einfach schnell gemacht werden soll mach ich mit C# (oder auch Java, wenn mich jemand dazu animiert) und wenn ich was skripten muss dann greif ich zu Python.

Also wird dieses Jahr wieder ein bisschen angepasst: Platformen statt Sprachen. Handy statt PC, Webbrowser statt “echter” Anwendung.

Jetzt muss ich mich “nur” noch nach einem Vehikel dafür umsehen. Es ist ja schon reizvoll alles in den “Microsoft Topf” zu werfen und sich auf Windows Mobile und / oder Silverlight zu fokussieren. Aber erstmal will ich noch ein bisschen die Alternativen prüfen.

Richard Stallman als Che und Bruce Schneier als Chuck Norris.

Die beiden gibts zu relativ humanen Preisen im geekz Shop. Wer lieber Donald Knuth oder Eric S. Raymond tragen möchte wird dort übrigens auch fündig. Meiner Meinung nach kommen letztere Shirts aber nicht an das geniale Design der hier vorgestellten ran.

Wirklich tragen wollen würde ich das Stallman Shirt allerdings eher nicht. Aber das hat politische Hintergründe, Fundamentalisten sind eher nicht so mein Fall. Egal was sie geleistet haben.

Why do programmers always mix up Halloween and Christmas?
Because Oct 31 equals Dec 25.

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:

Und dabei geht es mir nicht um den lieben Gott, Buddha oder Allah! Aber was (subjektiv gerade extrem häufig) einige Leute auf AMD, Intel, Linux, Windows, Java, C# (…) halten kann man nur noch als religiösen Eifer bezeichnen. Zumindestens finden sich in Diskussionen die gleichen Merkmale, wie man sie aus den “echten” Religionskriegen kennt.

1. Unbelehrbarkeit
   Beide Seiten werden auf ihrer Meinung beharren.
2. Unwissenheit
   90% der Argumente beruhen auf Vorurteilen.
3. Uneinsichtigkeit
   Die (maximal) 10% der stichhaltigen Argumente werden ignoriert, sofern sie unbequem sind.
4. Unendlichkeit
   Ein Konsens wird sich nicht finden.

Dabei könnte man diese Probleme durch eine einfache Einsicht umgehen: Die perfekte Programmiersprache (das perfekte OS (…)) gibt es nicht! Das sind alles Werkzeuge für spezifische Aufgabengebiete! Und mal passt halt das eine besser und mal das andere.

Sollte ich etwas Zeit finden, schreib ich nochmal ein bisschen mehr dazu.

Das Rails <openbook> ist übrigens ein guter Einstiegspunkt für alle, die es sich zutrauen Ruby (als Sprache) “nebenher” zu lernen. Ist zwar ungewohnt, aber der Syntax erschließt sich einem doch sehr schnell.

Jetzt muss ich mir nur noch eine passende IDE dafür zusammensuchen. Zum ausprobieren reicht mir zwar noch nano, aber auf Dauer … Theoretisch muss ich mir nur noch ein passendes Projekt zum Umsetzen überlegen, sonst macht das Projekt irgendwie nicht so recht Sinn.

Satz der Informatik:
Offenbar gelten:

1. Jedes Programm hat mindestens einen Fehler.
2. Jedes Programm kann durch geeignete Optimierungen um mindestens eine Instruktion verkuerzt werden ohne den Funktionsumfang zu verändern.

Daraus folgt per Induktion:
Jedes Programm kann bei gleichbleibendem Funktionsumfang auf eine einzige Instruktion verkuerzt werden, die nicht funktioniert.

• 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!

Wenn einem dann aber Leute plötzlich noch Ergänzungen, Wünsche oder sogar fertige Plugins zu einem schon etwas länger nicht mehr angeschauten Projekt schicken wirds dann doch etwas peinlich … Aber stimmt, es gibt da ja ein schon länger vor sich hin schlummerndes (überarbeitetes) Framework einer Tilelibrary. Ich werd da wohl mal wieder reinschauen!

Aus irgendwelchen Gründen hatte ich darüber nie so recht gebloggt, aber wenn man sich die Liste der bisherigen nicht erfolgreichen Projekte mal so ansieht ist das vllt auch besser so …

Naja, das “aktuelle” Framework hat mit den bisher hier zu sehenden Sachen nur am Rande was zu tun. Optisch mag es sich stark ähneln (zumindest der Editor), unter der Haube ist aber einiges passiert. Der ganze Editor wird momentan über Plugins aufgebaut und bietet ohne diese Plugins eigentlich nichts weiter als einen Projektbrowser (der nichtmal was anzeigt, weil … siehe oben). Dadurch kann (in der Theorie) jeder den Editor an seine Bedürfnisse anpassen.

In der Praxis existieren momentan nur zwei Plugins: jene für Tilesets und Gebiete. Und um nun auf den in der Überschrift angedeuteten Peinlichkeitsfaktor zu kommen … Es hat mir jemand noch ein drittes Plugin (Animationen) und viele Anregungen zu der Allgemeinen Architektur. Danke! Ich werds einpflegen!

• Man realisiert das ganze als Java Applet, was nicht unbedingt schwer fallen sollte. Immerhin ist Eclipse schon in Java geschrieben, der Sinn dahinter bliebe mir dann allerdings verborgen.
• Man will tatsächlich eine auf HTML / CSS / JavaScript basierte Lösung erstellen.

Ich hab die Antwort auf die Schnelle leider nicht gefunden, aber wenn man dort tatsächlich den zweiten Weg wählen sollte, frag ich mich echt was die Entwickler da gerade reitet. Trotz der immer schneller werdenden JavaScript Implementierungen, kann ich mir nicht vorstellen das eine solche Anwendung wirklich “flüssig” laufen würde.

Was will man also damit bezwecken? Soll Eclipse bald auf jedem Rechner verfügbar sein, auch ohne Java? Dann frag ich mich ernsthaft was für ein Entwickler Java Programmiert ohne eine Java Runtime zu haben. Zugegebenermaßen lässt sich Eclipse auch für andere Sprachen einsetzen, aber ich halte Java immer noch für das “Standbein” der IDE.

Sieht für mich nach einer immensen Verschleuderung von Resourcen aus, die man anderswo besser einsetzen könnte!

• 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!

Ist btw aus dem Spieleprogrammierer.de Forum, aber über sowas muss die Welt doch aufgeklärt werden *g*

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"