Allgemeine Frage zur Klassendeklaration/definition

Nexus

Da noch keine wirkliche Antwort gegeben wurde, will ich dir mal von dem Vorgehen abraten.

Bei std::string sind die Funktionen im Header inline definiert, weil es sich um ein Template handelt. Bei Templates muss sich die ganze Implementierung im Header befinden. Da es den Standardbibliothek-Entwicklern wohl zu umständlich war, die Definition von der Deklaration zu trennen (z.B. in einer anderen Headerdatei), haben sie sie gleich inline gemacht.

Bei normalen Klassen sollte man Memberfunktionen grundsätzlich nicht im Header definieren. Denn damit wird bei jeder Änderung der Implementierung wieder ein Neukompilieren aller Module, die den betreffenden Header einbinden, fällig. Indem du die Definitionen in .cpp-Dateien auslagerst, hast du nicht nur eine logischere Trennung und kurz gehaltene, übersichtliche Schnittstelle im Header, sondern du verringerst auch die Abhängigkeiten. Zusätzlich ist der zu parsende Code im Header kleiner, was die Kompilierzeit wiederum reduziert.

Dass Funktionen, die in eigenen Modulen definiert sind, weniger gut durch das Compiler-Inlining wegoptimiert werden können, stimmt auch nur begrenzt; bei Compilern mit Linkzeit-Codegenerierung (wie dem von MSVC++) sollte das keinen Unterschied machen.

P.S. Eine Klassendeklaration ist sowas:

class MyClass;

Eine Klassendefinition hingegen:

class MyClass
{
    // Member
};

Kóyaánasqatsi

Da noch keine wirkliche Antwort gegeben wurde, ...

Ich habe eine wirkliche Antwort auf die Frage:

Kann man Header-Dateien, in denen man Klassendeklarationen(Elemente und Methoden) schreibt auch direkt für die dazugehörigen Definitionen nutzen(...)?

gegeben.

pumuckl

Kóyaánasqatsi schrieb:

Da noch keine wirkliche Antwort gegeben wurde, ...

Ich habe eine wirkliche Antwort auf die Frage:

Kann man Header-Dateien, in denen man Klassendeklarationen(Elemente und Methoden) schreibt auch direkt für die dazugehörigen Definitionen nutzen(...)?

gegeben.

Du hast aber das PS nicht berücksichtigt, daher keine Antwort auf die eigentliche Frage gegeben.

Kóyaánasqatsi

Du hast aber das PS nicht berücksichtigt, daher keine Antwort auf die eigentliche Frage gegeben.

Doch, habe ich. Sie war vielleicht nicht tiefgründig oder ausführlich, aber es war eine Antwort.

Simon2

Kóyaánasqatsi schrieb:

Du hast aber das PS nicht berücksichtigt, daher keine Antwort auf die eigentliche Frage gegeben.

Doch, habe ich. Sie war vielleicht nicht tiefgründig oder ausführlich, aber es war eine Antwort.

Wer natürlich derart niedrige Anforderungen an eine Aussage stellt, um sie "Antwort" nennen zu dürfen, hat's auch nicht schwer - solle sich aber auch nicht wundern, wenn er wenig Freunde hat.

Im übrigen wäre ja auch eine falsche Antwort eine Antwort ...

Gruß,

Simon2.

Kóyaánasqatsi

wenn er wenig Freunde hat.

Habe ich wenig Freunde?

Halt doch einfach die Klappe Kóyaánasqatsi. Vor allem, da du ja offensichtlich nicht so viel Ahnung hast. Der OP fragte explizit nach dem _Sinn_ und es macht eben keinen Sinn.

Roger Wilco

Nexus schrieb:

Bei normalen Klassen sollte man Memberfunktionen grundsätzlich nicht im Header definieren.

Hallo Nexus,

Was heißt "normale Klasse"? Nicht-Templateklassen?

Die ursprüngliche Frage mal anders herum: Wann sind Definitionen im Header sinnvoll?

Nexus

Regt euch nicht über Kóyaánasqatsi auf. Die Tatsache, dass er früher als "way" unterwegs war, sagt eigentlich bereits alles.

Roger Wilco schrieb:

Hallo Nexus,

Was heißt "normale Klasse"? Nicht-Templateklassen?

Ja, so habe ich es gemeint.

Roger Wilco schrieb:

Die ursprüngliche Frage mal anders herum: Wann sind Definitionen im Header sinnvoll?

Wenn man weiss, was nicht sinnvoll ist, kann man doch auf das Sinnvolle schliessen.

Einige Leute definieren ganz kurze Methoden wie Setter und Getter im Header (inline). Ich schreibe deren Definitionen auch in Implementierungsdateien, Inlining-Optimierung sollte wie erwähnt trotzdem möglich sein. Ein wenig ist da auch Geschmackssache dabei.

Roger Wilco

Nexus schrieb:

Roger Wilco schrieb:

Die ursprüngliche Frage mal anders herum: Wann sind Definitionen im Header sinnvoll?

Wenn man weiss, was nicht sinnvoll ist, kann man doch auf das Sinnvolle schliessen.

Ich habe ja auch meine Frage erweitert und ganz allgemein von Definitionen gesprochen. Nicht nur von Klassen-Definitionen.

Nexus

Ah, ich dachte, es ginge immer noch um Memberfunktionen. Globale Funktionen verhalten sich übrigens gleich (abgesehen von "impliziten inline" innerhalb der Klasse, das bei globalen Funktionen nicht geht).

Klassen- und Namensraumdefinitionen sind unbestritten sinnvoll im Header. Typdefinitionen eigentlich auch, wenn sie benötigt werden (je nachdem auch innerhalb von Klassen oder Namensräumen).

Bei Variablen hingegen musst du die Definition in den meisten Fällen in der .cpp-Datei vornehmen, da du sonst Linkerfehler wegen mehrfach definierten Symbolen erhältst. Ausnahmen sind statische konstante integrale Variablen. Da kann es sinnvoll sein, den Variablenwert für den Compiler sichtbar zu machen (zum Beispiel bei Template-Metaprogrammierung). Andererseits gilt hier natürlich auch wieder, dass bei einer Änderung des Wertes ein Neu-Kompilieren aller header-benutzenden Dateien notwendig wird. Auch Konstanten von enum s müssen im Header definiert werden, sofern der enum -Typ bekannt sein soll.

skullyan

Bedanke mich für die ausführlichen Antworten.

Simon2

Kóyaánasqatsi schrieb:

wenn er wenig Freunde hat.

Habe ich wenig Freunde?

Habe ich das behauptet?

Gruß,

Simon2.

Simon2 schrieb:

Kóyaánasqatsi schrieb:

wenn er wenig Freunde hat.

Habe ich wenig Freunde?

Habe ich das behauptet?

Gruß,

Simon2.

Ja.

Simon2

way schrieb:

Simon2 schrieb:

Kóyaánasqatsi schrieb:

wenn er wenig Freunde hat.

Habe ich wenig Freunde?

Habe ich das behauptet?

Gruß,

Simon2.

Ja.

Wo?

Simon2 schrieb:

...
Wer natürlich derart niedrige Anforderungen an eine Aussage stellt, um sie "Antwort" nennen zu dürfen, hat's auch nicht schwer - sollte sich aber auch nicht wundern, wenn er wenig Freunde hat.

Im übrigen wäre ja auch eine falsche Antwort eine Antwort ...

Gruß,

Simon2.

Gruß,

Simon2.