Input & Output:

Visit blog to check out this spoiler

Und File Stream:

Visit blog to check out this spoiler

Vielleicht hat ja jemand Interesse und/oder Spaß daran.

bool valid_status(const App app, ref Status real_status = null) {

Doch endete mit einem Error, dass “real_status” kein lvalue sei. Das ist auch korrekt. Und damit war die Möglichkeit einen optionalen Parameter anzubieten dahin. Nun gab es vorerst nur einen weiteren Weg: zwei Methoden, einmal mit und einmal ohne zweiten Parameter. Eine typische Java Lösung.
Das gefiel mir nicht. Doch dann kam mir der Gedanke an Zeiger wieder und et voilà: es funktioniert bestens so:

bool valid_status(const App app, Status* real_status = null) {

In dem Methodenrumpf muss nun natürlich statt einfach: real_status = real_app_status; ein Sternchen vor “real_status”, um es als Zeiger zu kennzeichnen, also so: *real_status = real_app_status; aber das war es auch schon

Man sollte allerdings auf der Hut sein. Viele D Konstrukte besitzen eine “.ptr” property welche einen C Zeiger des Konstrukts zurückgibt, damit C Kompatibilität gewährleistet ist.
Es kann vorkommen, dass man nun etwas verwirrt ist und/oder unbedacht mit “construct.ptr” und “&construct” arbeitet.
Mir fiel es heute auf, als ich mit OpenGL hantierte und einem Buffer meine Vertices übergeben sollte, welche sich aus einem Vertex Array Vertex[] zusammensetzen.

Ich übergab glBufferData “&vertices” und wunderte mich, dass ich keine (korrekte) Ausgabe erhielt.
Doch dann erkannte ich, dass ich die “.ptr” property verwenden muss.

Eine kurze Erklärung dazu:
Arrays in C/C++ sind von sich aus im eigentlichen Sinne bereits Pointer und bei deren Übergabe als Parameter wird ein lediglich ein Pointer auf das erste Element dieses Arrays übergeben. Das ist auch der Grund dafür, dass man in sämtlichen OpenGL Tutorials (zumindest denen die C/C++ benutzen), auch immer nur vertices, anstatt &vertices (oder eben in D auch vertices.ptr) liest.

Eine kleine Veranschaulichung des ganzen:

import std.stdio;
 
struct Vertex {
	float x, y, z;
 
	this(float x, float y, float z = 0.0) {
		this.x = x;
		this.y = y;
		this.z = z;
	}
}
 
void main() {
	Vertex[] data;
	data ~= Vertex(10, 10);
	data ~= Vertex(100, 10);
	data ~= Vertex(10, 100);
	data ~= Vertex(100, 100);
 
	auto ptr1 = data.ptr;
	auto ptr2 = &data;
 
	writeln(typeid(typeof(ptr1)));
	writeln(typeid(typeof(ptr2)));
}

ergibt:

D:\D\D_Scripts\c_to_d_interfacing\SDL_1.3\tests>pointer
pointer.Vertex*
pointer.Vertex[]*

Kein Wunder also, OpenGL brauchte schließlich einen Pointer auf das gesamte Array. Und da wir in D und nicht in C sind, reichte ein “&vertices” oder gar nur “vertices” nicht aus.

Ich wollte es auch nur gesagt haben, es gibt sicher einige Situationen, wo dieses Wissen hilfreich sein könnte.

Für alle die es nicht wissen: eine const deklarierte Methode sieht folgendermaßen aus:

Das const “sagt” dem Compiler sozusagen, dass diese Methode das Objekt an sich nicht verändert.

Allerdings: wenn eine Eigenschaft eines Objekts verändert wird, ändert sich doch der komplette Zustand des Objekts. Also wozu als mutable deklarieren?
Debugging oder Logging Mitschnitte (oder derartig vergleichbares) verändern nicht wirklich den Zustand, jedenfalls nicht ausschlaggebend. Und für Debugging immer wieder das const auszukommentieren und in der Release wieder hinzuzufügen kann schon nach einer kurzen Weile etwas “nerven”.

Daher habe ich mir eine kleine Struktur geschrieben und einen dazugehörigen Test der die Benutzung demonstriert.
Damit sollte das mutable aus C++ emuliert werden. Eventuell hat ja jemand Interesse daran:

Visit blog to check out this spoiler

Nachtrag vom 12.01.2012

Ich habe die obige Struktur nochmal überarbeitet und an den Feinheiten geschliffen. Zudem habe ich nun daraus eine Klasse gemacht (geschah eher nach belieben als aus einem konkretem Grund).
Hier ist der Code:

Visit blog to check out this spoiler

In diesem Artikel möchte ich mich mit Vertex Buffer Objects, kurz VBO, beschäftigen.
Viele werden den folgenden Sachverhalt kennen oder zumindest in der Theorie nachvollziehen können.
Angenommen wir haben eine TileMap. Den sichtbaren Ausschnitt der Karte (View) werden wir mit sehr hoher Wahrscheinlichkeit nicht in jedem Frame ändern, sondern er wird mehrere Frames überstehen. Je nach Kartengröße eventuell sogar die gesamte Spielzeit, da gar kein Scrolling nötig ist.
Versteht sich von selbst: ist die gesamte Karte kleiner oder gleich groß wie das Fenster -> kein Scrollen notwendig, da alles bereits zu sehen ist.
Allerdings zeichnet man üblicherweise in jedem Frame wieder und wieder die gesamte Karte. Und das braucht bei größeren Karten eine Menge Rechenlast.
Man kann zwar das ganze etwas abmildern, in dem man von vorn herein nicht sichtbare Teile der Karte nicht zeichnet, aber die sichtbaren Tiles/Teile der Karte müssen dennoch immer und immer wieder über den Bus in den Grafikspeicher.

Hier ein Beispiel einer scrollbaren Karte (für Informatiker: bool scroll = sizeof(map) > sizeof(window) ? true : false;)
Anfangs Ansicht:

Visit blog to check out this spoiler

und die spätere gescrollte Ansicht, die zweite Hälfte wenn man so will

Visit blog to check out this spoiler

Beides Views, welche eine statische Ansicht repräsentieren, solang’ der Protagonist nicht so weit läuft, als das gescrolled werden muss.
Alle Render Aufrufe in dieser statischen Zeit sind absolute Verschwendung (im Normalfall).

Bei meinem D Framework Dgame hab ich es so gelöst:
Das aktuell gezeichnete Rechteck (der aktuelle View/Blickpunkt) wird zu Vergleichszwecken gespeichert, die Karte/die Tiles auf eine zweite Surface gezeichnet (die ebenso groß ist wie der View; was leider recht Speicherlastig werden kann) und dann auf den Bildschirm bzw. ins Fenster geblittet.
Wenn im nächsten Frame nun wieder der gleiche View gezeichnet werden soll, weil sich nichts verändert hat und der Ausschnitt der sichtbarne Karte somit gleich bleibt, dann wird die bereits gezeichnete Karte auf dne Bildschirm geblittet und wir sparen und das mühselige und Rechenlastige sowie nochmalige Zusammensetzen der Karte. Dies geschieht solange, bis sich eben etwas ändert. Die Heap Allokation und aufwendige Berechnungen der zusammenpuzzelung der Karte aus einem Tileset bleibt uns somit in nicht notwendigen Momenten (was etwa 90% der Spielzeit ausmachen kann) erspart. Solange wird also nicht gerade ein Side-Scroll und Jump ‘n Run Spiel erstellen, ist dies schonmal ein Anfang, Speicher, Heap Allokation und Rechenlast zu sparen.

Mit OpenGL gibt es zwei andere, wesentlich effizientere Methoden: Display Listen sowie Vertex Buffer Objects, kurz und im weiteren VBO. Ersteres ist in neueren Versionen bereits deprecated und sollte daher nicht mehr genutzt werden. Aus diesem und aus dem Grund, das VBO’s noch etwas effizienter und Performanter sind, werde ich nur auf diese eingehen.
VBO’s sind sozusagen eigene Speicherbereiche. Man reserviert sich faktisch Speicherplatz für Koordinaten von Texturen und ihren Platz auf dem Fenster. Oder nur Koordinaten um dann Primitive zu zeichnen.
Dies spart immens Rechenzeit, da man sich die herkömmliche Übertragung der Daten in dne Speicher spart, also sie gleich im Speicher verwahrt und ohne langwierige und aufwendige Übertragung per Bus jedes mal erneut dahin transportiert.
Ich habe mir mehrere Tutorials zu VBO’s durchgelesen, in meinem Haupt-Forum gepostet, mit diversen Leuten aus dem ICQ geschrieben.
Die wohl populärste Methode, Textur und Vertex Koordinaten zu speichern und somit Bildausschnitte und ihre Position im Speicher zu behalten stellte sich als etwas komplizierter heraus und da Tutorials und Hilfe oftmals versagten musste ich mir selbst über 3 endlose Tage alles zusammensuchen und -lesen, bis es endlich klappte. Damit es andere leichter haben, schreibe ich diesen Artikel.
Zunächst einmal die Funktionen die wir benötigen, ich lasse dabei mal außer Acht, das Texturen geladen und gezeichnet werden. Dazu soll dieses Tutorial nicht dienen.
Als da wären:

• glGenBuffers
• glDeleteBuffers
• glBindBuffer
• glBufferData
• glMap und glUnmap
• glDrawArrays

Was wir nun machen müssen ist zunächst einmal einen Buffer anfordern/generieren mit

GLuint vboId;
glGenBuffers(1, &vboId);

Nachdem wir nun einen Buffer bzw. eine ID für einen Buffer angefordert haben, müssen wir unsere Daten speichern.
Wir “binden” zunächst einmal nur Vertex Koordinaten:

Visit blog to check out this spoiler

glDrawArrays zeichnet uns ein schwarzes Rechteck an der Position (100|100) und mit der Größe 100×100 px,
wie hier zu sehen

Visit blog to check out this spoiler

Das glDisable(GL_TEXTURE_2D); ist deswegen notwendig, da ansonsten die Farbänderung von glColor3f sich nicht auf Primitive sondern lediglich auf die Farbkomponenten von Texturen ausüben würden. Wir würden das Rechteck also ansonsten nicht sehen.
glBindBuffer aktiviert bzw. bindet den Buffer, wie der Code Kommentar schon aussagt, und kennzeichnet ihn somit als aktuell. glBufferData überträgt dann die Daten in der angegebenen Größe in den Grafikspeicher.
Was glVertexPointer macht überlass ich mal dem Leser

Das wäre schon einmal ein Anfang. Wir haben nun ein schwarzes Rechteck, die Koordinaten dafür im Speicher und müssen sie nicht mehr über den Bus schicken. Wenn wir Position und/oder Größe ändern wollen, dann überschreiben wir mit dme gleichen Verfahren einfach die alten Buffer Daten.

Oder man guckt sich glBufferSubData. Was ich leider noch nicht groß getan habe, also eventuell folgt noch ein Update zu diesem Artikel.

» Primitive mittels eines Vertex Buffers im Speicher zu halten, ist auch eine Idee, die ich mir für Dgame 1.7 durch den Kopf gehen lassen werden.

Aber nun zum eigentlich genialen: Texturen oder Ausschnitte von Texturen gemeinsam mit ihrer Position im Speicher zu verwahren um (zumeist) statische bzw. sich langsam / wenig ändernde Objekte nicht immer und immer wieder zeichnen zu müssen. Wer sich hier noch fragt “Warum sollte man das vermeiden?” den lege ich nahe, noch einmal von vorne zu lesen, denn dann kam der Sinn der hinter VBO’s steckt wohl noch nicht ganz an.
Für dieses Vorhaben legen wir uns (zumindest in der einfachsten Variante) einfach einen zweiten VBO an, der dann statt der Vertex Koordinaten eben die Texturkoordinaten behinhaltet.
Das ganze Verfahren sieht äquivalent zu oberen Code Ausschnitt aus, jedoch nutzen wir statt des oben kurz angesprochenen glVertexPointer‘s glTexCoordPointer.

Wir wollen nun einen Teil dieses Tilesheets zeichnen. Und zwar an der Position (100|100) und der Größe von 100×100 px. Also exakt die Ausmaße unseres schwarzes Rechtecks.
Dazu machen wir folgendes:

Visit blog to check out this spoiler

Und schon haben wir einen Ausschnitt unserer Textur im Speicher und können ihn jederzeit ohne weitere Speicher Aufwendung rendern lassen.
Das Prinzip lässt sich sehr einfach auf TileMaps übertragen, wie man ja weiter oben anhand der Bilder sieht. Das zeichnen einer solchen Map (auch wenn man alle nicht sichtbaren Tiles nicht zeichnete) erreichte ohne VBO’s eine Framerate von 200 oder 300. Mit VBO’s bis zu 1160. Man sieht also den enormen Vorteil.
In Dgame 1.6 bekam ich beim dauerhaften Rendering eine maximale FPS von unter 60. Mit der oben genannten Behilfsmethode des selbstgemachten “Doppelbuffers” kam ich dann auf knapp 300.
Hier sieht man also auch sehr gut den Unterschied zwischen SDL 1.2 und OpenGL.

Ich hoffe der Beitrag war lehrreich und nicht zulang, bei Fragen, Kritik o.a. immer her damit.

1. Brauch ich OpenGL, also hab ich wirklich mehr Vorteile als Nachteile?
2. Ist das blitten und sonstige Handling mit GL Texturen wirklich um soviel performanter?
3. Soll ich für OpenGL Textur Nutzung eine eigene Klassen erstellen? Und wenn ja, soll sie von der Klasse Surface erben? Oder soll ich das binding an eine GL Textur in der Surface Klasse intern erledigen?

Was noch zu sagen wäre: seit etwas mehr als einer Woche bin ich auch auf Twitter anzutreffen; meine letzten Tweets können an der linken Seite jederzeit nachgelesen werden.

Ein Modul z.B. kann keine Funktionen oder Variablen nach außen hin kapseln, mit der Möglichkeit, später per Prefix oder (in C++ durch using namespace …) je nach Wahl gänzlich verfügbar zu machen. Die Betonung liegt dabei auf später & auf Prefix. Man kann auch nicht explizit verlangen, dass das Modul als namespace dienen soll, denn dann müsste man irgendwie erzwingen, dass das Modul per static import importiert wird.

Was man aber tun könnte: statische Variablen in einer (finalen) Klasse kapseln. Allerdings: was macht man bei Funktionen?

Wir versuchen folgendes:

class Vector {
	static bool contains(T, A...)(const T[] array, const A elements) {
		if (elements.length > array.length) {
			return false;
		}
 
		foreach (T e; elements) {
			if (Vector.position(array, e) < 0) {
				return false;
			}
		}
 
		return true;
	}
 
	static int position(T, A)(const T[] array, const A target) {
		foreach (uint index, T e; array) {
			if (e == target) {
				return index;
			}
		}
 
		return -1;
	}
}

und probieren einen Aufruf mit

int[] numbers = [1, 2, 3, 4, 5, 6, 8, 7];
 
if (Vector.contains(numbers, 1)) {
	writeln("enthält nummer");
}

Was erhalten wir? Ein nüchternes Ergebnis.
Wir erhalten einen Linker error:

main.obj(main)
Error 42: Symbol Undefined _D9namespace7__arrayZ
--- errorlevel 1

Und dazu Klassen für eine namespace emulierung missbrauchen? Das ist nicht gerade die feine Art.
Structs? Auch nicht viel besser. Zudem kommt es zum gleichen Fehler.
Aber Warum? Das ist eine wirklich gute Frage. Der Fehler entzieht sich eigentlich meinen Erklärungen.

Aber davon abgesehen gibt es eine wesentlich schönere und elegantere Art: einen kleinen “Hack”.
Dieser ermöglicht das was wir wollen ohne Linker Fehler und mit annähernd ähnlicher Benutzung, wie man es von C++ gewöhnt ist.
Dazu müssen wir nur aus der Klasse ein Template machen:

const string _type_check = "if (is(T == string) && !is(T == A)) return false;";
 
template Vector() {
	bool contains(T, A...)(const T[] array, const A elements) {
		mixin(_type_check);
 
		if (elements.length > array.length) {
			return false;
		}
 
		foreach (T e; elements) {
			if (array.position(e) < 0) {
				return false;
			}
		}
 
		return true;
	}
 
	int position(T, A)(const T[] array, const A target) {
		foreach (uint index, T e; array) {
			if (e == target) {
				return index;
			}
		}
 
		return -1;
	}
}

Und schon können wir ähnliche Expressions, wie die gewohnten aus C++, benutzen.
Das Äquivalent zu der C++ Expression

using namespace Vector;

wäre nun

mixin Vector;

Es ginge nun so etwas: array.contains(1); , sprich die Funktion “contains” auf das array anzuwenden (siehe dazu D: Array Expressions).
Der Zugriff per (renamed) namespace würde ähnlich gehen:
C++:

namespace V = Vector;

D:

mixin Vector V;

und somit V.contains(array, 1);

Allerdings: so etwas wie

using Vector::contains

oder gar die Erwartung, ohne mixin einfach via Vector.FUNCTION auf die jeweilige Funktion zuzugreifen klappt nicht.
Letzteres scheitert an der Template Anweisung, weswegen ein mixin immer Pflicht bei dieser kleinen Geschichte ist.
Aber wir lernen daraus: D ist flexibel. Vermisst man etwas (aus anderen Sprache o.a.), lässt es sich sehr leicht in D um- und einsetzen.

void Foo::get_something(const Bar & bar) const {
    std::cout << "Punkte: " << b.get_points() << std::endl;
}

In D ist es dagegen wie in Java oder C#: Objekte werden Standardmäßig als (Konstante) Referenz übergeben, auch genannt call by reference.
Allerdings nicht so bei Structs. Diese werden wie gewohnt als Kopie übergeben (call by value) und können damit einiges an Speicher und Laufzeit fressen.
Also bietet es sich hier an, wie in C++ zu verfahren und mit Referenzen statt mit Kopien zu arbeiten, um effizientere Programme zu schreiben. Aber wie groß ist eig. der Unterschied in D? Wegen dieser Frage habe ich mir in den letzten Tagen folgendes Benchmark Script geschrieben und diverse Parameter Storage Klassen (in*, out, ref, const, const ref, ref const) getestet, aber auch die normale Übergabe per Kopie.
Dabei ist out als nicht wirklich ernst zunehmender Konkurrent angetreten. Warum? Weil out alles auf die Initialisierungs- bzw Ausgansform zurücksetzt. So auch bei diesem Test, bei dem eigentlich x mal (drei Durchgänge á 500.000, sowie drei Durchgänge á 100.000) ein Array eines Struct mit 25.000 Elementen befüllt und dann intern durchgegangen und benutzt wurde.
Mittels out wurde natürlich wieder alles geleert. out kann somit als leerer Vergleich angesehen werden, sprich wie lange das Struct ohne 25.000 Array Elemente gebraucht hätte.

*Mir ist klar, das in nur ein alias für const scope ist, aber es ist hier dennoch der Vollständigkeitshalber & weil mich evtl. auftretende Unterschiede interessierten.

Benchmark Script:

Visit blog to check out this spoiler

Mit PC ist fort an mein Heim-PC mit Windows Vista, 32 bit, ca. 3 – 4 Jahre alt, gemeint.
Mit Laptop mein knapp 1 Jahr junger, Windows 7, 64 bit Laptop (Acer TimelineX).

500.000 Durchläufe á 25.000 Array-Elementen

#1 nicht ausgelastet (Vormittags / PC)

normal: timer.Node
Elapsed Time: total: 1137 sec. average: 0.002274 sec.
const: const(timer.Node)
Elapsed Time: total: 1138 sec. average: 0.002276 sec.
in: const(timer.Node)
Elapsed Time: total: 1101.5 sec. average: 0.002203 sec.
ref: timer.Node
Elapsed Time: total: 1098.5 sec. average: 0.002197 sec.
const ref: const(timer.Node)
Elapsed Time: total: 1097 sec. average: 0.002194 sec.
ref const: const(timer.Node)
Elapsed Time: total: 1095.5 average: 0.002191 sec.
out: timer.Node
Elapsed Time: total: 1056 sec. average: 0.002112 sec.

Daraus ergibt sich folgende Rangliste:

1. out
2. ref const
3. const ref
4. ref
5. in
6. normal
7. const

#2 nicht ausgelastet (Nachts / PC)

normal: timer.Node
Elapsed Time: total: 1123.109000 sec. average: 0.002246 sec.
const: const(timer.Node)
Elapsed Time: total: 1122.073000 sec. average: 0.002244 sec.
in: const(timer.Node)
Elapsed Time: total: 1123.176000 sec. average: 0.002246 sec.
ref: timer.Node
Elapsed Time: total: 1110.779000 sec. average: 0.002221 sec.
const ref: const(timer.Node)
Elapsed Time: total: 1089.992000 sec. average: 0.002179 sec.
ref const: const(timer.Node)
Elapsed Time: total: 1089.726000 sec. average: 0.002179 sec.
out: timer.Node
Elapsed Time: total: 1043.392000 sec. average: 0.002086 sec.

Daraus ergibt sich folgende Rangliste:

1. out
2. ref const
3. const ref
4. ref
5. const
6. normal
7. in

Hier haben also in und const die Plätze getauscht.

#3 nicht ausgelastet (früh morgens / PC)

normal: timer.Node
Elapsed Time: total: 1115.699000 sec. average: 0.002231 sec.
const: const(timer.Node)
Elapsed Time: total: 1119.301000 sec. average: 0.002238 sec.
in: const(timer.Node)
Elapsed Time: total: 1126.902000 sec. average: 0.002253 sec.
ref: timer.Node
Elapsed Time: total: 1083.569000 sec. average: 0.002167 sec.
const ref: const(timer.Node)
Elapsed Time: total: 1090.254000 sec. average: 0.002180 sec.
ref const: const(timer.Node)
Elapsed Time: total: 1091.030000 sec. average: 0.002182 sec.
out: timer.Node
Elapsed Time: total: 1039.632000 sec. average: 0.002079 sec.

Daraus ergibt sich folgende Rangliste:

1. out
2. ref
3. const ref
4. ref const
5. normal
6. const
7. in

normal und const getauscht sowie ref und ref const.

nicht ausgelastet (Nachmittags, während des Akku Ladens / Laptop)

normal: benchmark.Node
Elapsed Time: total: 1639.904000 sec. average: 0.003279
const: const(benchmark.Node)
Elapsed Time: total: 1653.237000 sec. average: 0.003306
in: const(benchmark.Node)
Elapsed Time: total: 1661.741000 sec. average: 0.003323
ref: benchmark.Node
Elapsed Time: total: 1634.890000 sec. average: 0.003269
const ref: const(benchmark.Node)
Elapsed Time: total: 1650.953000 sec. average: 0.003301
ref const: const(benchmark.Node)
Elapsed Time: total: 1651.356000 sec. average: 0.003302
out: benchmark.Node
Elapsed Time: total: 1551.027000 sec. average: 0.003102

Daraus ergibt sich folgende Rangliste:

1. out
2. ref
3. normal (hier liegt evtl. ein Messungsfehler vor)
4. const ref
5. ref const
6. const
7. in

Bis auf den vermutlichen Messungsfehler: deckungsgleich mit PC Messung #2.
Die Laptop Auflistung geht nicht in die gesamt Auswertung ein.

Zusammengefasst ergibt sich folgende Rangliste:

1. out mit 1046.3413 sec. im Durchschnitt
2. const ref mit 1092.4153 sec. im Durchschnitt
3. ref const mit 1093.0753 sec. im Durchschnitt
4. ref mit 1097.616 sec. im Durchschnitt
5. in mit 1117.173 sec. im Durchschnitt
6. normal mit 1125.27 sec. im Durchschnitt
7. const mit 1126.46 sec. im Durchschnitt

100.000 Durchläufe á 25.000 Array-Elementen

#1 relativ ausgelastet

normal: timer.Node
Elapsed Time: total: 242.059000 sec. average: 0.002420
const: const(timer.Node)
Elapsed Time: total: 243.650000 sec. average: 0.002436
in: const(timer.Node)
Elapsed Time: total: 243.978000 sec. average: 0.002439
ref: timer.Node
Elapsed Time: total: 237.292000 sec. average: 0.002372
const ref: const(timer.Node)
Elapsed Time: total: 236.699000 sec. average: 0.002366
ref const: const(timer.Node)
Elapsed Time: total: 236.697000 sec. average: 0.002366
out: timer.Node
Elapsed Time: total: 226.115000 sec. average: 0.002261

Daraus ergibt sich folgende Rangliste:

1. out
2. ref const
3. const ref
4. ref
5. normal
6. const
7. in

#2 kaum ausgelastet

normal: timer.Node
Elapsed Time: total: 224.289000 sec. average: 0.002242
const: const(timer.Node)
Elapsed Time: total: 226.320000 sec. average: 0.002263
in: const(timer.Node)
Elapsed Time: total: 228.803000 sec. average: 0.002288
ref: timer.Node
Elapsed Time: total: 219.821000 sec. average: 0.002198
const ref: const(timer.Node)
Elapsed Time: total: 220.465000 sec. average: 0.002204
ref const: const(timer.Node)
Elapsed Time: total: 220.279000 sec. average: 0.002202
out: timer.Node
Elapsed Time: total: 208.562000 sec. average: 0.002085

1. out
2. ref
3. ref const
4. const ref
5. normal
6. const
7. in

Hier tauscht zwar keiner, dafür wandert aber ref auf Platz #2.

#3 wenig ausgelastet

normal: timer.Node
Elapsed Time: total: 228.251000 sec. average: 0.002282
const: const(timer.Node)
Elapsed Time: total: 227.348000 sec. average: 0.002273
in: const(timer.Node)
Elapsed Time: total: 225.489000 sec. average: 0.002254
ref: timer.Node
Elapsed Time: total: 213.107000 sec. average: 0.002131
const ref: const(timer.Node)
Elapsed Time: total: 219.557000 sec. average: 0.002195
ref const: const(timer.Node)
Elapsed Time: total: 218.884000 sec. average: 0.002188
out: timer.Node
Elapsed Time: total: 209.011000 sec. average: 0.002090

1. out
2. ref
3. ref const
4. const ref
5. in
6. const
7. normal

Hier tauschen in und normal ihre Plätze.

Zusammengefasst ergibt sich folgende Rangliste:

1. out mit 214.5626 sec. im Durchschnitt
2. ref mit 223.406 sec. im Durchschnitt
3. ref const mit 225.2866 sec. im Durchschnitt
4. const ref mit 225.5736 sec. im Durchschnitt
5. normal mit 231.533 sec. im Durchschnitt
6. const mit 232.4393 sec. im Durchschnitt
7. in mit 232.7566 sec. im Durchschnitt

Fazit:
Auch wenn es einige Unterschiede zwischen 100.000 und 500.000 Durchläufen gibt, ist wohl der Durchlauf bzw. die drei Durchläufe mit 500.000 am eindeutigsten.
Allerdings sieht man so oder so, dass die Familie der Referenzen (sprich: ref, const ref, ref const) immer an der Spitze stehen, mit erheblichen Unterschieden zu den Restlichen.
Sollte also jmd. ein struct in seinem Programm gebrauchen, sollte er genau darüber nachdenken, wie er damit umgeht.
Wenn man das Struct bisher als Parameter übergab, dessen Eigenschaften auslas, eine neues, geändertes Struct des gleichen Typen daraus generierte und dann zurückgab, sollte man vielleicht von nun an auf Referenzen (ref) zurückgreifen, und die Änderungen an dieser Referenz ausführen (sich das return und damit die lokale Kopie also sparen, und die Laufzeit verringern).
Bsp:

import std.stdio;
 
struct Node {
	int[] array;
 
	this(const int n) {
		for (uint i = 0; i < n; i++) {
			array ~= i;
		}
	}
 
	void doStuff() const {
		foreach (const int i; array) {
			writeln(i);
		}
	}
}
 
void work_with_ref(ref Node n) {
	n.array[0..2] = 42;
}
 
void main() {
	Node n = Node(4);
 
	n.doStuff();
	work_with_ref(n);
	n.doStuff();
}

Für den Fall, dass man wirklich eine Kopie brauchte, weil an dem Original keine Änderungen geschehen sollten, sollte das ganze dennoch nicht als normaler Parameter übergeben werden, denn auch hier könnte man das Struct als Referenz übergeben (und somit wieder Laufzeit einsparen).
Damit Änderungen per Referenz vermieden werden, sollte man es in diesem Fall (wie wir aus C++ noch wissen) als Konstante Referenz (const ref/rerf const) übergeben.
Nun kann man wie gewohnt fortfahren, hat aber dennoch keine Kopie.
Bsp:

import std.stdio;
 
struct Node {
	int[] array;
 
	this(const int n) {
		for (uint i = 0; i < n; i++) {
			array ~= i;
		}
	}
 
	void doStuff() const {
		foreach (const int i; array) {
			writeln(i);
		}
	}
}
 
Node work_with_const_ref(const ref Node n) {
	Node copy = Node(n.array.length);
 
	foreach (int i, const int e; n.array) {
		copy.array[i] = (e + 1) * 10;
	}
 
	return copy;
}
 
void main() {
	Node n = Node(4);
	Node copy = work_with_const_ref(n);
 
	n.doStuff();
	copy.doStuff();
}

Diese Feature sind ja auch schön und gut, wären aber noch nicht Grund genug, dass im Phobos-Framework keine einzige Klasse wie vector oder list zu finden sind. Nun ja, der wahre Grund hierfür ist, dass D noch ein weiteres Feature bietet: die sogenannten Array-Extensions. Es handelt sich dabei um Funktionen, die das Array in ihrer Funktionalität erweitert und man gleichzeitig den Eindruck gewinnt, dass die Funktion eine Memberfunktion des Arrays ist. Dabei ist folgende Regel zu beachten: Je allgemeiner man die Funktion implementiert ist, desto mehr Arrays haben die Möglichkeit, die Funktion zu nutzen. Es empfiehlt sich also generisch, sprich mit Templates zu programmieren.

Kommen wir nun zum praktischen Teil des Artikels. Bei den ersten Versuchen mit D habe ich eine Funktion vermisst, welche überprüft, ob ein String bzw. ein Array of Char einen Buchstaben bestimmten Buchstaben besitzt. Also habe ich folgende Funktion geschrieben:

bool contains(char[] str, char c) {
   foreach(char item; str) {
      if (item==c) return true;
   }
   return false;
}

Nun musste ich für die Überprüfung des Array of Char immer diese Funktion aufrufen und ihr als Argument einmal das Array und den Vergleichsparameter übergeben:

char[] str = "Hallo Welt!";
bool bContainsY = contains(str, 'y');

Das wird auf Dauer zugegebenermaßen ganz schön unübersichtlich. Doch Dank D würde auch folgendes funktionieren:

char[] str = "Hallo Welt!";
bool bContainsY = str.contains('y');

Man könnte bei dem folgenden Code-Abschnitt also glauben, dass es sich bei str um ein Objekt handelt. In Wirklichkeit aber wird die Funktion contains aufgerufen. str wird der Funktion als erstes Argument, y als zweites Argument übergeben (Im Prinzip arbeiten so auch Klassen, da den Memberoperationen intern der this-Zeiger zugewiesen wird ). Damit man diese Extension auch für andere Arrays verwenden kann, muss man von den Templates Gebrauch machen:

bool contains(T)(T[] array, T com) {
   foreach(T item; array) {
      if (item == com) return true;
   }
   return false;
}

Allerdings sind diese Beispiele eher an D 1.x angelehnt, ein Äquivalentes D 2.x Beispiel wäre so etwas:

bool contains(T, A...)(in T[] collection, in A elements) {
	if (elements.length > collection.length) {
		return false;
	}
 
	foreach (const T element; elements) {
		if (collection.get_position(element) < 0) {
			return false;
		}
	}
 
	return true;
}
 
int get_position(T)(in T[] collection, in T element) {
	if (collection.length == 0) {
		return -1;
	}
 
	foreach (uint key, const T _element; collection) {
		if (_element == element) {
			return key;
		}
	}
 
	return -1;
}
 
void main() {
	string[] names = ["Hans", "Foo", "bar", "quatz"];
 
	assert(names.contains("Hans"));
	assert(!names.contains("Hans", "foo"));
	assert(names.contains("Hans", "Foo"));
}

Achtung: Nicht immer sind diese allgemeinen Extensions erwünscht. Man stelle sich nur vor, dass man Objekte des Types SpaceShuttle in einem Array verwaltet und das Array mit der Funktion saveToFile() erweitern will. Hier Templates zu verwenden würde vollkommen gegen die Logik der generischen Programmierung gehen, da man die Technik zur allgemeinen Programmierung für eine spezifische Funktion benutzen würde.

Doch was ist, wenn man die Referenz des Objektes manipulieren muss, um beispielsweise das Element am Ende des Arrays zu löschen? Richtig, man ändert den Modifizierer des 1. Parameters in ref:

T pushLast(T)(ref T[] array) {
    T tmp;
    if (array.length == 0) {
        return tmp;
    }
    tmp = array[$-1];
    array = array[0..$-1];
    return tmp;
}

An der vorherigen Funktionalität ändert sich dabei nichts:

char[] str = "So la la....";
str.pushLast();

Fazit: Die Array-Extensions sind ein sehr nützliches Feature was in 99% aller Fällen eine extra Klasse zu Verwaltung eines Arrays überflüssig macht.

Wer Interesse an einigen nützlichen Funktionen hat, findet diese entweder in der Dgame 1.6 Version oder kann sie sich hier gleich kopieren:

Visit blog to check out this spoiler

Ich hatte genau so etwas nun auch in D geplant:

Aber ich erhielt folgenden Fehler:

rect.d(18): Error: function rect.Rect.x conflicts with template rect.Rect.x(T) at rect.d(10)

Es scheint so, als würde die normale nicht-Template Methode mit der Template Methode konkurrieren. Ändert man die Template-Methode zu einer nicht-Template Methode ab

void x(short x) {
	_x = x;
}

Gibt es auch keinen Fehler mehr. Es muss also an der Template Deklaration liegen.
Tja, wie macht man nun einen einigermaßen guten Fix um ein derartiges Feature dennoch zu unterstützen?
Ich habe nested sowie mixin Templates erfolglos probiert und mir fiel schließlich nur eine Lösung ein:
Die nicht-Template Methode muss eine werden:

T x(T = short)() {
	return _x;
}

Wir legen also eine explizite Template Methode an, und weisen dem Template-Typ den default-Typ “short” zu.
Anstelle von short könnte man natürlich auch einfach typeof(_x) schreiben.

Und wie man sieht: es funktioniert.
Wie gesagt, keine Ahnung, ob das so gewollt ist oder nicht, aber mit diesem kleinen “Hack” funktioniert es trotzdem.

Als kleine Sicherheit könnte man noch eine explizite if Abfrage in die Methode einbauen, die überprüft, ob es sich bei T, und damit dem Return-Typ, tatsächlich um ein “short” handelt:

T x(T = short)() const if (is(T == short)) {
	return _x;
}

Nachtrag

Nachdem ich das hier in den Bug-Docs gefunden habe, sollte statt

T x(T = short)() {
	return _x;
}

auch so etwas funktionieren

short x()() {
	return _x;
}

Vielleicht kennt jemand das Problem schon:
Angenommen, man hat eine derartige Template Struktur

Und des Weiteren hat man ein Element wie Vector2f v1 = Vector2f(1.5, 2.3); und muss es, aus irgendeinem Grund, in einen Vector2s umwandeln/casten.
Wie stellt man das am besten an?

Zunächst habe ich versucht den cast operator zu überladen á la

stieß dabei allerdings auf das Problem, dass, sofern ich etwas wie Vector2s v2 = cast(short) v1; machen wollte, eine Fehlermeldung bekam, die mir höflichst andeute, dass, wenn ich schon zu short caste, der Compiler auch einen short und keinen Vector2s zurück erwartet, logisch eigentlich.
Das nächst liegende wie etwa Vector2s v2 = cast(Vector2s) v1; schlug auch Fehl; nun hatte ich zwar den Typ Vector2s, aber wie bekomme ich nun den eigentlichen Typ, sprich short, heraus?
Gar nicht, aber das braucht man auch nicht, wenn an dem Code etwas verändert:

Wozu kann man das gebrauchen?

Damit man z.B. eine Vector2f Struktur einfach einer Klasse/Methode übergeben kann, die eine Vector2s Struktur erwartet: class.method(cast(Vector2s) v1); ohne das man eine Zwischenvariable anlegen muss.

Aber ich war noch nicht zufrieden.
Ich wandte mich an das D-Forum und mit entsprechender Hilfe von darkdragon haben wir eine Möglichkeit ausgeklügelt, welche ein casten wie dieses hier erlaubt Vector2s v2 = v1; und ebenso ein leichtes Handling was die Übergabe bzw. somit auch das konvertieren angeht, z.B. Vector2s v3 = Vector2s(3.14, 2.5); oder, wie im obigen Fall beschrieben zur Übergabe einer Vector2f Struktur an eine Methode die eig. eine Vector2s Struktur erwartet: class.method(Vector2s(v1));.
Im ersteren Fall sieht man deutlich, dass ich hier float Werte übergebe, obwohl man denken würde, dass Vector2s explizit shorts erwartet. Das ist nun aber egal, sie werden beim Aufruf automatisch umgecastet. Bequem und einfach.
Der ganze Zauber beruht auf dem (mehrfachen) überschreiben des opCall Operators. Allerdings dient der opCall Operator gleichermaßen als Ersatz für den bisherigen Konstruktor, denn dieser ist mit diesem “Hack” – im Fachjargon Metaprogrammierung genannt – nicht zulässig; der Compiler meldet einige schwerwiegende Fehler Aber wie gesagt, opCall dient als entsprechender und – in diesem Fall – sogar besseren Ersatz. Hier der Code:

Weiß jemand, warum die Methoden als static deklariert sein müssen?

Visit blog to check out this spoiler

Allerdings geht das noch einfacher, denn D akzeptiert – * genau wie C++ – Template Konstruktoren und damit werden unsere ganzen opCall’s überflüssig

Wenn man nun etwas wie
Vector2f v1 = Vector2f(3.14, 2.5);
hat und es in eine bereits bestehende Vector2s Struktur überführen möchte, kann man entweder den opAssign Operator überschreiben

und kann dann so etwas hier machen:

oder man macht es mittels casting:

Oder aber, man überschreibt den opCall Operator erneut:

dann könnte man das ganze so in etwa lösen:

Je nachdem was einem lieber ist.

Das C++ Äquivalent

Und die Anwendung:

Anhang

* Template Konstruktoren

Die C++ Variante: