A
Also der leaf dimensionsparameter ist frei wählbar, sonst wäre der Aufwand ja total doof und für die Katz...
Ich hoffe eine Speicherandordnung zu finden, wo ich
n-Dimensionale Daten mit 3d-Now/mmx effizienter binärsuchen kann.
Oder ich möchte die Konvergenz (zeitlich) parallel für möglichst viele Dimensionen, je nach dem wie groß der zu suchende Typ eben ist und wie oft ich den typ auf einmal in die Prozessorregister bekomme.
Am liebsten in einem Array, aber das wird wohl nix.
Deswegen hier die leafs...
Wobei man eigentlich sowas wie ne eigene Speicherverwaltung machen kann, und
dann der sagen, wie der Speicher angefordert werden soll, also dass er in einem Stück bleibt für die ganze klasse zum beispiel (eben das Auslagerungsproblem in den Griff bekommen) und dann immer placement new...
Den Speicher würde ich bei C/C++ nie vergessen, der gehört da dazu wie Butter bei de Fische =)...
Ich glaube wenn man den Speicher bei C/C++ nicht im Blick hat, dann wirds kritisch..
Ich denke aufgerollt liegt im Stack dann ein array wie
leaf<double,3> _leaf( (char), (short), (int))
/// -> wird zu: char [sizeof(char)+sizeof(short)+sizeof(int)] /// im stack
/// Und dann muss beim unroll erste Rekursion
/// -> T1 val = (double) ???<- ist ein char und es verbleibt
/// char [sizeof(short)+sizeof(int)]
/// etc...
Jetzt ist natürlich die Frage, wo ich auf den casting mechanismus zugreifen kann. Man könnte dann auch eigene typen casten.