Templateklassen kann man ja leider nur in der Headerdatei implementieren, auch wenn das natürlich logisch ist, aber halt leider die Header aufbläht.

Gut, Frage ist jetzt, ob es einen Unterschied macht, ob ich die Klasse in der Definition implementiere oder nicht:

// Variante1: OK?
template<typename T>
class Class
{
public:
Class()
{
// Mehr als drei Zeilen Code
};
};

// Variante2: Oder auf jeden Fall so?
template<typename T>
class Class
{
public:
Class();
};

template<typename T>
Class<T>::Class()
{
// Mehr als drei Zeilen Code
}

Der Vorteil an Variante 1 ist halt, dass ich mir die template<typename T>-Zeile sowie das T in der Class-Zeile spare. Denn das ist hier zwar noch harmlos, kann aber natürlich dick aufblähen. Und der Compiler macht Funktionsimplementierungen in der Klassendefinition ja eh nicht inline, wenn sie zu lang sind.

Nachteil wäre dann für mich nur, dass man auf einen Blick nicht alle Methoden/Attribute der Klasse sieht. Aber damit kann ich offen gestanden leben, da ich einen Übersichtlichkeitszuwachs dennoch sehe und man das in Java ja z.B. auch gewöhnt ist.

Thoughts?

Edit: Templasteklasse zu Klassentemplate geaendert

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

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.

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?

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.

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

double ist genauer als float aber langsamer.

Wie kommst du da drauf?

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

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.

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

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

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 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.

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.