Design Frage - Unions oder einzelne Klassen?
-
Moinsen
Naja, mal wieder ein ziemlich kryptischer Titel, aber ich hoffe, dass trotzdem sich jemand in diesen beitrag verirrt
Ich überarbeite zur Zeit ein wenig das Design meines DirectX Wrappers. Nun habe ich schon zwei Klassen gefunden, bei der mir diese Frage aufkam:
zB Habe ich 3 Vektor Klassen, die die D3DXVec2/3/4* Funktionen wrappt. Da der Code jedoch fast komplett gleich ist, dachte ich mir, man könnte das doch in eine Klasse packen. frage ist: aber wie? ich könnte natürluich ein dynamisches float array benutzen, aber ich würde gerne die D3DXVECTOR2/3/4 Struktur verwenden. Also kam ich auf die Idee, ein Union in die "Universal Vektor Klasse" zu schreiben. Genauso habe ich es mir für texturen überlegt, da bei "normalen", cube- und volumetexturen die funktionalität auch ähnlich ist. Frage: wie findet IHR ein solches design? habt ihr das ähnlich gemacht? oder habt ihr für verschiedene texturen auch verschiedene klassen? oder habt ihr es ganz anders gemacht? und wenn ja wie?
bin gespannt auf eure meinungen und vorschläge,
danke im voraus (<-- höhö :p
)
-
Ableiten. Bei Vektor-Addition muß doch nur die Anzahl der Elemente gewusst werden, der Rest ist gleich...
-
"Ableiten."
sorry, aber das versteh ich nich. was soll ich denn wovon ableiten?
-
Babbo schrieb:
"Ableiten."
sorry, aber das versteh ich nich. was soll ich denn wovon ableiten?er meint vererbung.
Ich habe dazu verschieden Klassen und mach mir dazu keinen stress. Die Rechenoperationen für die verschiedenen Vektoren sind unterschiedlich, also macht es imho keinen sinn dafür ein und die selbe Klasse zu benutzen. Es ist außerdem im Kontext deutlicher, verschiedne Klassen zu benutzen.
-
template baseclass +vererbung wirkt manchmal wunder...
-
"Er meint vererbung"
jaja, das hab ich schon verstanden, wusste nur nicht, was wovon erben sollte.
hab jetz mal angefangen, meine vektor klasse mit unions zu schreiben, ziemlich umnständlich ^^ werde deshalb wohl doch einzelne klassen nehmen.
falls aber noch jemand vorschläge hat, immer posten, bin sehr neugierig ^^
achja und danke für die bisherigen posts
-
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?