Woche 2 (20.10 – 26.10)

Fortschritt:

Der Resourcenmanager hält nun alle Resourcen in einer Map, kann sie zurückgeben nach Adresse, Handle oder Pfad. Der Manager lagert Resourcen nach Priorität, letzer Nutzung und Größe aus, wenn die Resourcen eine vorgegebene Größe erreichen. Die Resourcen selbst sind ein Template, welches die Typspezifischen Funktionen spezialisiert.

Die ToString Funktion ist nun genauso wie die getClassName- und getSize-Funktion ein Macro. Auf diese Weise kann ich die Makroargumente zur Compilezeit festlegen und muss so keine Variablen und Funktionen nutzen, die ja während der Laufzeit mit Werten initialisiert werden müssen. Coole Sache.

Probleme:

Es geht nur sehr zögerlich voran:

Mit dem Resourcemanager gibt es Probleme. Ursprünglich hätte ich die Resourcen gerne als Templates gehabt, bei denen nur eine Load-Funktion pro genutztem Typ spezialisiert werden muss – Allerdings ist es gar nicht so leicht das ganze in eine STL-Map zu packen, dort muss ich dann nämlich mit dynamischen casts um mich werfen. Mein Ansatz für eine neue Resource nur eine (Load-)Funktion zu spezialisieren scheint nicht zu klappen – Für die dynamic_casts bräuchte ich eine Kontrollstruktur welche mir den richtigen Typ castet… die Idee einen User später in meinem fertigen Manager rumcoden zu lassen ist mir weniger lieb als wenn er Objekte ableiten muss.

Ausserdem stecke ich viele Stunden bei kryptischen Fehlern, welche nach unrelevanten Codeänderungen auftreten. Nach langem langem Suchen bemerke ich dass ein fehlendes Leerzeichen(!) am Ende einer Headerdatei schuld war. o.O

ToDo:

Das Dilema mit dem Manager lösen. Dann endlich Smart-Pointer implementieren.

Woche 1 (13.10 – 19.10)

Fortschritt:

• Das Design steht soweit:
  Alle Objekte werden vom IMemObjekt abgeleitet. Dieses kümmert sich um Garbage Collection und grundsätzliche Funktionalität wie toString funktion, Zurückgeben der Objektgröße usw.

• Davon abgeleitet werden die Manager (Ressourcen, Kernel, Logging, Sound….) sowie inGame-Objekte, welche wiederum als Interface für zeichenbare und nicht zeichenbare Objekte dienen.

• Von den Managern werden die benötigten Objekte und Subsysteme abgeleitet (Resourcen, Streams…)

• → das Ganze wird fast vollständig top-down programmiert.

Implementiert sind jetzt ein Singleton, das „Über-Objekt“, ein einfaches to-String Makro, sowie ein Macro zum Zurückgeben der Größe. Für die Bestimmung von Engpässen und Performancefressern gibt es jetzt einen selbstgeschriebenen Profiler.

Probleme:

In C++ ist Vererbung sehr unterschiedlich zu Java implementiert. Während in Java eine abhängige Instanz von allen Parent-Klassen erzeugt wird ist dem in C++ nicht so: im Grunde besteh keine Abhängigkeit zwischen abgeleitetem und ableitendem Objekt – Das macht die Implementierung einer toString-Funktion sehr schwierig. Fürs Erste gebe ich mich damit zufrieden nur einen Default-toString auszuführen, dem man zusätzliche Attribute für jede abgeleitete Klasse mitgeben kann – eine doppelt abgeleitete Klasse erbt also nur die toString Funktionalität des IMemObjects, nicht die der unmittelebaren Parent-Klasse.

ToDo:

Ein Resourcenmanager ist der nächste Schritt, mit dem ich String-Tables laden kann, welche ich dringend für meinen Profiler brauche. Ausserdem wäre ein Smart-Pointer toll, damit ich einen Garbage-Collector implementieren kann.

Unsere Tastatur

Als ich mich heute auf mein Projekt einstellen wollte, mich reflektierend in meiner mitgenommenen schwarzen Cherry Tastatur verlor und nachsinnend in einer Welt von Templates, Makros und Funktionspointern zu driften drohte, fiel mein Blick auf einige unauffällige Tasten auf eben jener Tastatur. Wie wunderlich, waren diese doch nahezu unberührt von der vielzahl von Ablagerungen, welche sich doch sonst überall auf den Tasten breit machten. Nur eine dezente Staubschicht hatte sich sanft um die Objekte meiner Aufmerksamkeit gelegt:

Das man mit der PRINT-Taste unter Windows Screenshots erzeugt gilt als Common Knowledge, aber wusstet ihr dass die Kombination [ALT]+[PRINT] einen Screenshot des aktiven Fensters erzeugt? Sehr geschickt für Blogger.

Die SCROLL-LOCK-Taste, (oder einfach Rollen) erfüllte in längst vergangenen Zeiten die Funktion des Scroll-Rades, man konnte also den Bildausschnitt mit [ROLLEN]+[PFEIL OBEN/UNTEN] bewegen ohne den Cursor verschieben zu müssen. Die gleiche Funktion unterstützt das Visual Studio, allerdings nicht mehr mit der ROLLEN-Taste, sondern mit [STRG], sehr geschickt wenn man beim Programmieren keine Lust hat immer zwischen Tastatur und Maus zu wechseln.

Heute ist diese Taste unter Windows im Grunde völlig unsinnig geworden.  Mit [STRG]+2x[ROLLEN] lässt sich unter Windows XP zwar noch ein Memory Dump generieren, allerdings ist dies nur für Fehleranalysen nötig und die Funktion standardmäßig deaktiviert, in Vista soll diese Funktion gar nicht mehr existieren.

Jemand sollte sich die Mühe machen auszurechnen wieviel Geld gespart würde wenn die Taste mitsamt der damit verbundenen LED von den Tastaturen verbannt würde.

Die PAUSE/UNTBR-Taste war einmal dafür da das laufende Programm abzuschießen.

Ich erinnere mich an meine VB-Zeit (hach ja, als Programmierung noch so einfach war…), damals ließ sich mit [STRG]+[PAUSE] die Ausführung abbrechen, ein Relikt aus der DOS-Basic Zeit. Heute funktioniert das nur noch bei der Ausführung von Batches.
Gemeinerweise wird diese Abschießen-Funktion unter Linux durch die Kombination [STRG]+[C] erfüllt, ein hinterhältiger Kniff um Windows-User zu verwirren.

Für alle interessant: der BIOS-Start lässt sich noch heute mit einem Druck auf [PAUSE] pausieren und mit erneutem Druck wieder fortgesetzt werden.

Damit ist auch dieses Thema abgehandelt und der geneigte Leser hoffentlich wieder ein wenig klüger geworden

Tour review!

Endlich!

Nach längerer Arbeit habe ich unsere Fahrradtour zum Comer See in eine Google-Earth Tour umgewandelt – Umgewandelt, das heißt in diesem Fall Meter für Meter rekonstruiert und mit Bildern und Notizen gefüttert.

Dafür ist GoogleEarth ein wirklich tolles Tool.

Und dank der guten Abdeckung ist es mir ziemlich gut  gelungen den Weg nachzuvollziehen.

Wer also darüber nachdenkt einmal selbst die Alpen zu überqueren dem sei diese Tour ans Herz gelegt, schließlich weiß man hinterher immer mehr.

Für Suchende hier noch weiterführende Informationen:

Wir sind zu zweit gefahren, ein Cross-Rennrad, ein Treckingbike.
Das Gepäck wog etwa 12 kg pro Person, inklusive Zelt.
Zu beachten:

• Am Besten eine Kreditkarte mitnehmen, die Abdeckung ist in fast ganz Europa besser als hier in Deutschland.
• Ein Zelt ist unglaublich wichtig: Wir sind in den Bergen in schwere Gewitter geraten, ohne Zelt wären wir nie durchgekommen.
• Kleidung: Auf jeden Fall genug Termokleidung und schwere regenfeste Klamotten. Dicke Socken mitnehmen.
• Genug gelbe Säcke mitnehmen. Die eignen sich hervorragend zum Einpacken von Schlafsack, Isomatte etc. und wiegen fast nichts.
• Genug Pausen machen: Den Splügenpass schafft man zwar mit durchschnittlicher Kondition, aber tagelang Bergauffahren ist kein Spass für die Gelenke: Das Ganze macht mehr Spass wenn man ab und zu Pause macht, die Gegend anguckt und ein kühles Radler trinkt. Lieber (so wie wir) einen Tag länger einplanen als nachher abbrechen zu müssen.
• Für die Tour genügt eigentlich GoogleMaps als Kartenmaterial. Zumindest wir sind ziemlich gut damit klar gekommen. In der Schweiz sind die Routen vorbildlich ausgeschildert, in Italien gibts sowieso keine Fahrradwege.
• Ich bin mit einem Crossrennrad gefahren, dh. bestückt mit 700 × 32 C Reifen(um einiges dicker als Rennreifen); Mit noch dünneren Reifen wäre ich allerdings nicht weit gekommen – Zu oft geht der Weg durch Kies und Geröll – Wenn es dann noch regnet rutscht man mehr als man fährt.
• Zu guter letzt: Die Tröte. Zu Beginn noch als Gag gemeint, erwies sich diese Tröte als äusserst nützlich. Vor allem auf der Südseite (Italien) des Passes geht es durch extrem enge, unbeleuchtete Tunnels. Autos hupen beim reinfahren – und Fahrradfahrer am besten auch.

Die Tour gibts hier zum Komplettdownload(18.8MB)!

Ich hoffe das Material hilft weiter!

C++ Anfängerfehler

Ich ordne meinen Code ja sehr gerne in Definition und Implementierung, was die Lesbarkeit etwas erhöht und einfach alles ein bisschen verhübscht. Leider führt sowas aber auch leicht zu ziemlich dummem Fehlerverhalten, vergisst man beispielsweise ein Semikolon am Ende einer Klassendefinition, bekommt man kryptische Fehlermeldungen, die auf einen völlig anderen Teil des Codes verweisen.

Etwas ungleich böseres ist mir gestern passiert: Meine Ressourcendatei wollte partout nicht mehr kompilieren, die Fehlermeldung war ein EOF beim Auslesen des dazugehörigen Headers. Seltsamerweise hatte ich diesen aber schon eine längere Zeit nicht mehr verändert o.O
Nach einigem Rätseln gab ich auf und googlelte die Meldung, die Lösung des Problems war recht einfach:

ich hatte wohl aus Versehen ein Leerzeichen am Ende der Headerdatei gelöscht. Also: Leertaste, kompilieren und der Spass tut wieder.

Der Hintergrund: Headerfiles werden im Grunde ja einfach an den Ort der Includeanweisung kopiert. Durch einen unglücklichen Zufall kann es nun passieren dass direkt auf die Include-Anweisung Code folgt, das Ergebnis: Der letzte Codeschnippsel des Headers klatscht sich an den ersten Schnippsel der cpp -.-

In meinem Fall wurde die Kompileranweisung #endif zerschossen und resultierte in einen EOF-Error.

Naja.

Muss man ja nur wissen.

Also in Zukunft: Am Ende des Headers einfach ein Leerzeichen machen, dann kann nichts passieren.