Klassentemplates aufteilen sinnvoll?

Pria schrieb:

ich denke gerade über den Sinn nach, ob man templateklassen aufteilen sollte oder nicht.

Interessant. Ich glaube, du bist der erste, der sich darüber Gedanken macht, kein Wunder findet man im Internet nichts darüber.

Eisflamme

Verstehe ich nicht. cpp-Datei geht ja gar nicht oder geht es jetzt nur um die Spezialisierungen? Die kann man da reinschreiben. Ansonsten kann man nur eine andre Datei anlegen, so was wie .h.impl oder was auch immer und die am Ende der Header-Datei inkludieren.

Den Hauptvorteil, dass Änderungen an der Impl-Datei nur diese Übersetzungseinheit betreffen, hat man jedoch trotzdem nicht gewonnen. Ist also nur Kosmetik, bringt aber überhaupt nichts.

hustbaer

@Eisflamme
Klar kann man ne .cpp Datei nehmen. Sagt ja keiner dass die .cpp Datei nicht im Include-Folder liegen darf, bzw. dass man sie nicht mit #include reinholen dürfte.

hustbaer schrieb:

Klar kann man ne .cpp Datei nehmen. Sagt ja keiner dass die .cpp Datei nicht im Include-Folder liegen darf, bzw. dass man sie nicht mit #include reinholen dürfte.

Ja, klar kann man. Macht man aber trotzdem nicht, wie so vieles, das man auch noch kann.

Es gibt keinen Grund, von der Konvention abzuweichen, die Endung .cpp für Implementierungsdateien und .hpp/.inl für Header zu verwenden. Eine Abweichung führt nur zu Problemen, da Compiler aufgrund dieser Konvention Übersetzungseinheiten bilden.

hustbaer

@X.
Hab ich was anderes behauptet?

Eisflamme

Klar kann man .cpp als Nicht-ÜE-Datei nehmen, aber das ist ja nun irreführend ohne Ende. Finde meine Implikation in Ordnung.

Pria

Es war nicht die Frage ob es generell mit .cpp files geht, somndern ob es tatsächlich sinnvoll ist, gerade für umfassende änderungen

http://stackoverflow.com/questions/495021/why-can-templates-only-be-implemented-in-the-header-file

Eisflamme

Der Artikel beschreibt doch schön, was man tun kann und was davon der Nutzen ist.

Es hat in meinen Augen keinen Nutzen außer dass es evtl. manchen übersichtlicher erscheint. Außer Du implementierst eben wie Vorschlag 2 vom Stackoverflow-Artikel die ganzen Spezialisierungen. Aber dann geht in meinen Augen der ganze Witz von Templates verloren (für den Fall, dass man Spezialisierungen ohnehin braucht, ist hier keine Argumentation notwendig).

Wenn Du am Ende der Header-Datei etwas inkludierst und in diesem Inkludium etwas änderst, muss natürlich trotzdem alles neukompiliert werden, was auch den Klassentemplate-Header inkludiert. Für umfassende (oder genau so: marginale) Änderungen schießt die Compiletime also genau so in die Höhe. Ich kenne gerade keine anderen Faktoren, weswegen man .h/.cpp trennt, vielleicht kann das jemand ergänzen.

Nach was man immer Ausschau halten sollte, sind Funktionalitäten, die die Typinformation nicht zwingend brauchen. Oft kann man den grössten Teil einfach so implementieren und muss dann nur noch einen typsicheren Wrapper drumrum bauen.

Für einen Baum zum Beispiel:

struct basic_node {
  basic_node *parent, *left, *right;
};
template <typename T> struct node : basic_node {
  T data;
};

Das Iterieren im Baum lässt sich schön auf basic_nodes ausführen, kann also in eine cpp-Datei geschoben werden.

Eisflamme

Wieder was gelernt, gute Idee.

Pria

Mal angenommen ich habe beispielsweise eine hypothetische Klasse

template<typename T> struct Math
{
  T DoSomethingComplicated(T value);
}

in einer dll oder was auch immer, mit einer überschaubaren Anzahl an sinnvollen Möglichkeiten für T

int, float, double

und ich würde nach und nach an der Performance von

DoSomethingComplicated

arbeiten und hätte das in einer vielzahl anderer Klassen und Ausführungscode eingebunden oder wenn ich eine neue Version meines moduls erzeugen würde (mit/ohne den anwendungs-code neu zu kompileren), gäbe es dann einen praktischen Nutzen es in eine .cpp auszulagern oder macht der reine header hier immer noch am meisten sinn?

Pria

Eisflamme

~~Irgendwie glaube ich, dass Du nicht mitliest oder nicht verstehst, wie Klassentemplates funktionieren... Jedenfalls glaube ich nicht, dass ich hier weiter helfen kann.~~

Wie würdest Du es denn konkret auslagern? So richtig Auslagern ansich geht ja erstmal nicht, wie wir jetzt lang und breit festgestellt haben. Du kannst Spezialisierungen in die .cpp-Datei stecken und für diese alles brav optimieren. Spezialisierungen eines Templates würde ich aber ohnehin immer in eine cpp-Datei stecken (ist das nicht sogar notwendig? Habe es gerade nicht gemacht). Wenn Du dann in der cpp-Datei etwas änderst, dann kannst Du nachher theoretisch auch nur die erzeugte dll austauschen, wenn die Header sich nicht geändert haben.

=> Dann nützt das durchaus was.

Pria

ok, also wenn ich mich weider auf das Beispiel beziehe, und das Ganze anschließend so auslagere

template<typename T> T Math<T>::DoSomethingComplicated(T)
{ .... }

template struct Math<int>;
template struct Math<float>;
template struct Math<double>;

weil ich der Ansichz bin, dass dies für den Verwendungszweck der dll durchaus ausreichend ist und ich warscheinlich updates im reinen Ausführungscode machen werde, sprecht ihr mir zu, dass es sinn machen kann dies so zu schreiben?

Warum nicht

int doSomethingComplicated(int a);
float doSomethingComplicated(float a);
double doSomethingComplicated(double a);

In der cpp arbeitest du dann mit Templates um den Code nicht duplizieren zu müssen.

Davon abgesehen ist es höchst seltsam, floats und doubles wild zu mischen und sogar Rechnungen anzustellen, die für Ganzzahlen (mit ihren Hardwareexceptions) und Kommazahlen (mit ihren Spezialwerten Inf/NaN) genauso gehen. Mir fällt irgendwie kein gutes Anwendungsszenario ein.

Bringe bitte ein realitätsnäheres Beispiel.