Klassentemplate in Klassendefinition implementieren?

Eisflamme

Okay... Ich dachte, es wäre fast sicher, dass gängige Compiler längere Funktionen niemals inlinen. Da das nicht der Fall zu sein scheint, gehören die Implementierungen dann imo raus.

brotbernd

Das ist eher geschmackssache als eine Frage des inlinens. Die Compiler wissen ziemlich gut was gut zu inlinen ist und was nicht und machen da was sie wollen (wenn man sie lässt). Die können sogar (bzw. eher der Linker) bei entsprechendem Schalter aus unterschiedlichen Quelldateien inlinen.
Ich schreib irgendwie meistens alles in der Klassendefinition. Aber ich schreib auch recht kleine Klassentmplates, so dass das nicht so unübersichtlich wird.

Eisflamme

Ich nutze halt für OpenGL irgendwie bei fast jeder meiner Klassen template-Parameter, weil das unglaublich praktisch ist, da man die Wahl zwischen float und double hat. Jetzt habe ich fast nur template-Klassen und dafür den Vorteil, dass ich bei Benutzung entscheiden kann, ob ich float oder double verwende...

Ist es nachteilig, normale Klassen im großen Stil gegen Templateklassen zu tauschen?

Nexus

Eisflamme schrieb:

Ist es nachteilig, normale Klassen im großen Stil gegen Templateklassen zu tauschen?

Ja, vor allem weil die Kompilierzeiten so stark steigen können. Das betrifft nicht nur die Implementierungen selbst, sondern alle dafür benötigten Header, die nun ebenfalls von allen Benutzern eingebunden werden.

Aber wenn dein Compiler es unterstützt, kannst du z.B. explizite Instantiierungen benutzen. Andere Möglichkeiten wären die Verwendung von dynamischer Polymorphie, und – als Mittelweg – kombinierte Techniken wie Type Erasure. Aber diese können das Problem auch nur bedingt lösen.

Verwendest du bei dir innerhalb des gleichen Programms manchmal float und manchmal double? Sonst wäre ein globales typedef eine Möglichkeit.

Übrigens: Du meinst Klassentemplate und nicht Templateklasse.

Eisflamme

Ok, wg. Klassentemplate vs Templateklasse les ich nochmal die FAQs, da hatte ich das Mal gesehen vorhin.

Der globale typedef ist ziemlich schlau. Der bietet sich eigentlich gut an. Aber ich muss z.T. auch andere OGL-Methoden aufrufen je nach Typ. Soll ich dann mit Präprozessor arbeiten oder wie würdest Du das geschickt machen?

Nexus

Eisflamme schrieb:

Aber ich muss z.T. auch andere OGL-Methoden aufrufen je nach Typ. Soll ich dann mit Präprozessor arbeiten oder wie würdest Du das geschickt machen?

Du könntest oft benötigte Funktionen mit einer Überladung wrappen:

void Vertex2(GLfloat x, GLfloat y)
{
    glVertex2f(x, y);
}

void Vertex2(GLdouble x, GLdouble y)
{
    glVertex2d(x, y);
}

Aber das ist natürlich relativ viel Aufwand. Kürzer aber hässlicher könntest du mit dem Präprozessor etwas machen:

#define TAKE_FLOAT // Präprozessor-Schalter

#ifdef TAKE_FLOAT
 #define TYPE float
 #define GLFUNC(Name) Name##f
#else
 #define TYPE double
 #define GLFUNC(Name) Name##d
#endif

int main()
{
	GLFUNC(glVertex2)(3, 4);
}

Aber das würde ich mir gut überlegen.
Willst du dich nicht auf einen Typen festlegen? Warum benutzt du überhaupt zwei?

Willst du dich nicht auf einen Typen festlegen? Warum benutzt du überhaupt zwei?

Berechtigte Frage.

Für große Headeransammlungen kann man aber vorkompilierte Header nehmen. Wie das in Verbindung mit dem g++ darfst mich aber grade nicht fragen. Ich kenne es nur von Visual Studio und da ist das ein Segen was die Kompilierzeit angeht.
rya.

Eisflamme

double ist genauer als float aber langsamer. Schon gibt es Szenarien, wo ich Mal lieber float und Mal lieber double benutze. Man koennte auch sagen, ich tue das aus Unwissenheit, aber Weitblick klingt besser.

Funktionsueberladungen finde ich eigentlich ziemlich ok, da ich vorher bei meinen Templatespezialisierungen ja auch zwei hatte. Dann mache ich das so, danke.

SeppJ

Eisflamme schrieb:

double ist genauer als float aber langsamer.

Wie kommst du da drauf?

Dravere

SeppJ schrieb:

Eisflamme schrieb:

double ist genauer als float aber langsamer.

Wie kommst du da drauf?

Wenn ich mal mit etwas Hervorhebung zitieren darf:

Eisflamme schrieb:

double ist genauer als float aber langsamer. Schon gibt es Szenarien, wo ich Mal lieber float und Mal lieber double benutze. Man koennte auch sagen, ich tue das aus Unwissenheit, aber Weitblick klingt besser.

Wahrscheinlich war seine Überlegung, dass ein float 32 Bit hat und ein double 64 Bit und es daher für den double mehr Takte braucht, weil er grösser ist. Dass eine CPU heutzutage aber eine FPU besitzt und alle Gleitkommazahlen mit 80 Bit rechnet egal ob float oder double , weiss er wahrscheinlich nicht

Grüssli

Dravere schrieb:

SeppJ schrieb:

Eisflamme schrieb:

double ist genauer als float aber langsamer.

Wie kommst du da drauf?

Wenn ich mal mit etwas Hervorhebung zitieren darf:

Eisflamme schrieb:

double ist genauer als float aber langsamer. Schon gibt es Szenarien, wo ich Mal lieber float und Mal lieber double benutze. Man koennte auch sagen, ich tue das aus Unwissenheit, aber Weitblick klingt besser.

Wahrscheinlich war seine Überlegung, dass ein float 32 Bit hat und ein double 64 Bit und es daher für den double mehr Takte braucht, weil er grösser ist. Dass eine CPU heutzutage aber eine FPU besitzt und alle Gleitkommazahlen mit 80 Bit rechnet egal ob float oder double , weiss er wahrscheinlich nicht

Grüssli

Und welcher Datentyp ist nun für OpenGL der bessere?
Ich verwende eigentlich immer floats, da ich bisher keine Daten hatte wo ich damit Probleme festgestellt hätte...
Das Thema bzw ein Vergleich würde mich hier auch interessieren :).
rya.

Dravere

scorcher24@public.pc schrieb:

Und welcher Datentyp ist nun für OpenGL der bessere?
Ich verwende eigentlich immer floats, da ich bisher keine Daten hatte wo ich damit Probleme festgestellt hätte...
Das Thema bzw ein Vergleich würde mich hier auch interessieren :).
rya.

Bisher war es eigentlich float . Ich kenne ein paar Gründe, bin aber auch nicht so der Profi in OpenGL, weiss also auch nicht wie aktuell diese sind:
1. Gerade für zum Beispiel Spiele war float immer ausreichend von der Genauigkeit.
2. float frisst weniger Speicher.
3. Wenn ich mich recht erinnere, werden 64 Bit Gleitkommazahlen in gewissen Bereichen (z.B. Shader) gar nicht unterstützt.

Grüssli

Eisflamme

Ja moment Mal. Tut mir Leid, aber wenn ich in OpenGL alle Operationen mit double statt float laufen lasse, ist das Programm tatsächlich um ein Vielfaches langsamer. Zusätzlich spielt das von den Ressourcen eine Rolle: Wenn ich ein Model mit double-Koordinaten laufen lasse, verbraucht es logischerweise den doppelten Platz und da Modelle viel Ressourcen einnehmen ist das auch ein Punkt.

Ich weiß nicht. Ich würde mich zumindest ungern auf float festlegen, wenn es eben auch anders geht.

brotbernd

Das läuft ja dann auch nicht auf einer CPU sondern GPU.

Dravere

brotbernd schrieb:

Das läuft ja dann auch nicht auf einer CPU sondern GPU.

Und eine GPU ist darauf optimiert Gleitkommazahlen-Operationen zu machen.

@Eisflamme,
Hast du denn überhaupt irgendein Argument, welches gegen das ausschliessliche Benutzen von float spricht? Hast du einen Anwendungsfall, wo du die zusätzliche Genauigkeit brauchst? Sonst machst du dir nämlich nur das Leben schwer, ohne davon einen Nutzen zu haben.

Grüssli

brotbernd

Dravere schrieb:

brotbernd schrieb:

Das läuft ja dann auch nicht auf einer CPU sondern GPU.

Und eine GPU ist darauf optimiert Gleitkommazahlen-Operationen zu machen.

Ja aber (bisher) eher mit (single) floats. Manch ältere Karte kann gar nix mit double und castet jedes mal.

Eisflamme

Hm, nein, bisher faellt mir nicht ein, wo ich double brauche. Aber ich bin Anfaenger in dem 3D-Zeug und kenne mich da nicht wirklich gut aus, ist gut moeglich, dass so was spaeter Mal wichtig wird, kA...

Gut, dann kann ich's vll. auch spaeter wieder aendern. Aber ein typedef ist doch praktisch und gut. Eigentlich kann es doch irgendwann ueberall Sinn machen, Typen wieder zu ersetzen. Hab auch von einigen, die in dem 3D-Bereich und auch C++ nicht schlecht fit sind gehoert, dass sie eigentlich nur noch mit typedefs, size_type und stdint arbeiten und die normalen Datentypen gar nicht mehr verwenden, da es immer je nach Portierung oder von 32 auf 64 Bit sein kann, dass ein Datentyp mehr Sinn macht als der andere.

Mir fehlen da die Grundlagen, um das selbst ausreichend zu erlaeutern.