Template Klassen in header und source files
-
@`??????????:
In den Beispielen bis jetzt war immer die ganze Klasse eine Template.
Jetzt hab ich eine normale Klasse mit einer Template Funktion.
-
same difference ....
-
same story...
-
Eben nicht.
Es kam ja heraus, dass man die Funktion in der C++ Datei vor dem includieren der Header-Datei schreiben soll.
Das geht ja nicht, weil die Funktion ja Member der Klasse ist, die in der Header-Datei deklariert wurde.
Jetzt klar was ich meine?
-
Gap schrieb:
Eben nicht.
Es kam ja heraus, dass man die Funktion in der C++ Datei vor dem includieren der Header-Datei schreiben soll.
Das geht ja nicht, weil die Funktion ja Member der Klasse ist, die in der Header-Datei deklariert wurde.
Jetzt klar was ich meine?Da hast du was falsch verstanden. Der hack war dass du die implementation in irgendeine datei (warum nicht .cpp) schreiben kannst und diese dann am ende der headerdatei in den header includierst.
BTW würde die datei eher .ipp nennen.
Kurt
-
Oops, dann hilfts mir eh nicht, weil ja genau die Übersicht dadurch verloren geht.
Ich will halt die Klasse in einer Header Datei und alle Funktionen der Klasse in einer C++ Datei haben.
Das geht nicht, oder?
PS:
Ich hab mal in einem Tutorial gelesen, das zu einem sauber Programmier Stil gehört, dass man nie eine C++ Datei includieren soll.
-
you got it.
-
Gap schrieb:
Das geht nicht, oder?
PS:
Ich hab mal in einem Tutorial gelesen, das zu einem sauber Programmier Stil gehört, dass man nie eine C++ Datei includieren soll.Stimmt alles.
Es geht nicht, weil die meisten Compiler (bis auf Comeau) export nicht unterstützen. (Ich muss sogar zugeben, dass ich export nur vom hörensagen kenne, weil ich es beim G++ nie benutzen kann.)Und keine Cpp Dateien einbinden. Dafür gibt es Headerfiles und Linker.
mfg
-
Ich will halt die Klasse in einer Header Datei und alle Funktionen der Klasse in einer C++ Datei haben.
Geh doch mal mit Logic ran und versuch zu begreifen, was da vor sich geht ....
Du sagst in nem header, das du ne klasse / Funktion generisch als template baust. Das heisst, der Compiler kann aus dem template erst dann maschinencode bauen, wenn du das template voll parametrisiert benutzt.
Also wird das template am benutzer (jede cpp datei, die das template direkt oder indirekt einbindet) compiliert und dann dazugelinkt. Normal iss der compiler dann nur noch so schlau, templates mit selben parametern nich doppelt zu generieren, sondern dann nur noch fuer den linker symbole auf das schon in ner anderen cpp datei eingehaengten templates zu generieren.Mit ner eigenstaendigen cpp datei fuer das template wuerde das nich funktionieren ... warum ? weil alle cpp dateien unabhaengig compiliert werden, und mit welchen paramatern soll er das template in diesem falle bauen ?
Also definition und deklaration im falle eines templates zu trennen, iss unnatuerlich, und klar, das das nur mit "schmutzigen tricks" geht ...
Deshalb, templates gehoeren normalerweise in den header ausgepraegt. Wenn du templates baust, die so unuebersichtlich sind, dass du den starken drang hasst, deklaration von der definition zu trennen, solltest dein Design eh noch mal ueberdenken.
Templates sollten kurz und knackig sein, ansonsten blaeht es bei uebermaessiger nutzung deinen erzeugten code nur unnutz auf ....Ciao ...
-
RHBaum schrieb:
Mit ner eigenstaendigen cpp datei fuer das template wuerde das nich funktionieren ... warum ? weil alle cpp dateien unabhaengig compiliert werden, und mit welchen paramatern soll er das template in diesem falle bauen ?
Also definition und deklaration im falle eines templates zu trennen, iss unnatuerlich, und klar, das das nur mit "schmutzigen tricks" geht ...
Nö. Was Du beschreibst ist das Inclusion Model, was auch jeder gewohnt ist und kennt. Nebenbei gibt es auch noch das Separation Model, dass die separate Kompilierung von Templates in eigenen cpp Dateien vorsieht (was man genau mit dem Schlüsselwort export erreicht).
Soweit, so gut. Das sind die Models an sich. Das Separation Model, wie es im Standard beschrieben wird, ist aber unzureichend spezifiziert und führt zu ganz ernsthaften Problemen. Z.B. wird das Template in einer separaten Datei kompiliert. Aber je nach dem muss es -huch- plötzlich Symbole aus anonymen namespaces anderer cpp-Dateien kennen können. Eine absolut widersprüchliche Eigenschaft. In der cpp-Datei des Templates laufen auf einmal auch massig verschiedene includes zusammen, die durch die versteckten Abhängigkeiten entstehen. Und was alles passieren kann, wenn der Code mit Templateparameter T=Klasse A plötzlich die includes von Templateparameter T=Klasse B sieht, kann sich wohl jeder ausmalen (geschweige denn die Kollision von Symbolen aus anonymen namespaces). Deswegen Finger weg vom Separation Model und dem Schlüsselwort export.
-
no risk - no fun.
-
yo! as you wish
Hier noch was zu lesen dazu:
Teil1: http://www.gotw.ca/publications/mill23.htm
Teil2: http://www.gotw.ca/publications/mill24.htmhttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf
Das sollte endlich mal in die FAQ
(ich hoffe doch mal, da steht's noch nicht :D)
-
@7H3 N4C3R
Es gibt zu dem Thema bereits einen FAQ-Beitrag:
http://www.c-plusplus.net/forum/viewtopic-var-t-is-39467.htmlIch werde die drei von dir genannten Links gleich mal hinzufügen...
-
Aaah, ich glaub ich bin aus dem Thead-Titel in den FAQ nie so richtig schlau geworden (und hab auch deshalb nie reingeschaut :))
Die SuFu tut's momentan auch nicht so richtig, hab ich den Eindruck. Eine Suche nach export hat nix gebracht.
-
7H3 N4C3R schrieb:
Aaah, ich glaub ich bin aus dem Thead-Titel in den FAQ nie so richtig schlau geworden (und hab auch deshalb nie reingeschaut :))
Na dann ändere ich den doch einfach