Design Frage - Unions oder einzelne Klassen?
-
Babbo schrieb:
falls aber noch jemand vorschläge hat, immer posten, bin sehr neugierig ^^
Machs, wie otze gesagt hat.
bzw. sehe ich hier keine basisklasse... also nur templates
-
Templates sind natürlich für sowas 'ne geniale Sache. Hab mir selbst vor geraumer Zeit Vektor und Matrix Klassen damit geschrieben. Vererbung halt ich persönlich für ungeeignet, da praktisch immer ein Element hinzukommt und sich somit jede Funktion ändert und man sie dann eh neu machen muss. Mach erstmal eine Klasse fertig, dann kopieren, und dann jede Funktion durchgegehen und für das hinzugekommene Element anpassen.
Kannst ja auch mal hier schauen, da hab ich was über meine Vektor Klasse geschrieben.
-
vielleicht geht noch mehr,wenn man von den dx standard vectoren weggeht, sondern komplett auf nen eigenen vector umschwenkt,n dimensionale vectoren sind ja wirklich einfach über templates zu erstellen...
-
So 'ne n-Dimensionen-Vektor Klasse war zB das erste, was ich gemacht hab. Ich halte es trotzdem für richtiger für Vektor2/3/4 Klassen spezielle Versionen zu implementieren, da man 'ne Menge Optimierungen einbauen kann, wie zB der Wegfall von Schleifendurchläufen, etc.
-
schleifen? wo? wieso hat mein n dimensionaler vector keine schleifen sondern nur zur compilezeit ausgeführte rekursionen?mach ich was falsch?*angst*
-
Wieso schreibt ihr euch eigentlich alle eigene Vektoren/Matrizen-Klassen?
1. bieten doch die D3DX Vektoren/Matrizen alle Operationen die man so braucht und 2. wird der Code doch nur langsamer, wenn ihr eure Klassen umwandeln müsst, um sie an die D3DX Funktionen zu übergeben (wenn ihr nicht gerade das selbe Speicherlayout wie die D3DX Klassen benutzt und ne Zeigerkonvertierung durchführt, was aber mies aussieht)
-
meine vertexklassen haben den cast schon überladen(aufjedenfall vector 2-4)
-
otze schrieb:
schleifen? wo? wieso hat mein n dimensionaler vector keine schleifen sondern nur zur compilezeit ausgeführte rekursionen?mach ich was falsch?*angst*
Ob iterativ oder rekursiv ist letztendlich egal, beides läuft auf Laufzeitoverhead hinaus. Seitdenn du hast einen wirklich smarten Compiler oder löst das ganze selbst mit Metaprogramming (worauf ich bei deiner Aussage tippe) auf. Nur ist das nicht immer sinnvoll. Ein Vektor mit mehreren 1000 Elementen kann so recht schnell den compilierten Code aufblähen.
interpreter schrieb:
Wieso schreibt ihr euch eigentlich alle eigene Vektoren/Matrizen-Klassen?
Ersten zwecks Lerneffekt und zweitens gibt es Leute, die Vektoren nicht nur für Spieleprogrammierung nutzen. Und ich hab keine Lust dann auf das DX SDK zurückzugreifen. Wenn sich jemand lediglich auf DX beschränkt, hast du natürlich Recht. Es macht dann keinen Sinn sich erst was selbst zu basteln.
-
Hier mal was von Rucy Rucker:
#define THREEDVECTORS /* Comment in the THREEDVECTORS switch to make the types "cVector, cMatrix, cRealBox" be cVector3, cMatrix3, and cRealBox3. Comment THREEDVECTORS out to make the same types be, respectively, cVector2, cMatrix2 and cRealBox2. You might be surprised to learn that the program runs essentially at the same speed with 2D instead of 3D vectors! Very little percentage of the computation must be going into that third argument. Sample figure: on my machine a 31 critter Dambuilder runs at 40-41 updates per second with 3D vectors and at 41-42 updates per second with 2D vectors. Maybe 3% speed pickup. The 3D games don't seem to work at all with 2D vectors, maybe there's an issue with the viewer code assuming 3D. Instead of having this #ifdef switch on typedefs, I could have written a common cVector interface and have cVector2 and cVector3 inherit from it. But since I use these guys so often, I'm concerned that making their methods virtual might slow the programs down. Same for cMatrix. I haven't actaully tested if it would run slower if I had a cVectorBase that cVector2 and cVector3 inherit from, I really should. But no time right now. As mentioned, in the Pop framework, we use "ambiguous" cVector and cMatrix types, and try and write the code so it would work for any dimensionality. I disambigutate the actual dimensionality of these in this vectortransformation.h file and realbox.h by lines like: typedef class cVector3 cVector; typedef class cMatrix3 cMatrix; typedef class cRealBox3 cRealBox; */
Man sieht also, man braucht gar keine 2D Vektoren. :p
-
WTF is Rucy Rucker?