Templates richtig in dlls exportieren
-
sdfgh schrieb:
Du darfst Templates auch nicht separat in einer *.cpp Datei unterbringen. Warum? Liegt an den Templates selbst. Evtl. hat einer Lust, das genauer zu erklären

Na dann erklär mir das ma, so dass ichs einsehe, denn normal funzt das bei mir sonst wunderbar

b2t, wie funktioniert das dann zum beispiel bei den containern in bibliotheken, zb Qt QVector?
-
indem die Implementierung in der Headerdatei liegt?

Es gibt im C++ zwar das Schlüsselwort export, mit welchem man die Implementierung auslagern könnte, aber das unterstützt AFAIK nur der Comeaucompiler und auch noch wahnsinnig unperformant. => implementierung in den Header (du kannst natürlich die Implementierung eine Implementierungsdatei schreiben (mit irgend ner Endung) und die in der Header includen, wenn dir das besser gefällt^^
-
hm ok bleibt mir wohl nix anderes übrig warum schert sich denn keiner darum?
-
piXelshooter schrieb:
hm ok bleibt mir wohl nix anderes übrig warum schert sich denn keiner darum?
worum?
-
piXelshooter schrieb:
warum schert sich denn keiner darum?
Typischer Fall von "ist einfach so"
Templates sind ja auch kein richtiger Code an sich, sondern quasi nur ein Mittel, um Code zu erstellen.
Schreibt man z.B.int i = 5;irgendwo in den Quelltext, wird daraus Assembler-Code, den der Prozessor ausführen kann. Wenn man eine Template-Klasse/-Funktion deklariert, ist das noch gar nichts. Erst wenn man sie verwendet, z.B. eben durchvector<xyz> myvar;, wird der eigentliche Code erzeugt. Makros z.B. kann man auch nicht exportieren
-
Ich nehm an, weil keiner wirklich weis
wie man dieses Feature implementieren kann.Wie macht den der ComeauCompiler das?
Der kann doch nicht im voraus Wissen
welche Klassen und Typen ich in den Templates verwende?
-
-
jup, die liefern in ihrem front-end die einzig bekannte implementierung für den export von templates. wenn ich mich jetzt recht erinnere, sind das wohl einige mannjahre entwicklungsarbeit gewesen... das ist der grund, warum es sonst nicht implementiert ist.
-
In diesem Buch wird ausführlich beschrieben, wie das mit export funktioniert und was man sonst noch über Templates wissen will. Wenn es jemand verstanden hat
kann er/sie es ja mal kurz hier wiedergeben...
-
edit @ badestrand
ok, das n arg^^
frag mich halt nur warum fast alle die ideen u standards so locker nehmen
-
Checker&Murckser schrieb:
Ich hab den Link nicht ganz durchgelesen,
wenn ich aber die relevanten Teile
richtig verstanden habe erzeugt der Compiler
zusätzliche Dateien (Endung .et und .ti)The ". et" files only inform Comeau C++ about the location of exported template definitions; they do not actually contain those definitions. The sources containing the exported template definitions must therefore be made available at the time of instantiation (usually, when prelinking is done)
Und in diesen Dateien steht dann wo die Template Definition zu finden ist.
Ich kann aber jetzt nicht z.B. eine Bibliothek erzeugen
mit Templates (sagen wir mal sowas wie die STL, eben nur
als fertige Bibliothek) und dann einfach dagegenlinken.//EDIT
With exported templates, users of the library must also have access to the source code of the exported templates and the information contained in the associated ". et" files, as discussed above.
Kann man nicht, steht weiter unten.
Note that the export facility is not a mechanism for avoiding the publication of template definitions in source form.
Wo ist dann der Sinn von export?
Da finde ich die Lösung mit den Templates im Header eleganter.
-
Also wenn ich mich recht erinnern kann, dann habe ich das mal mit __declspec(dllexport) und templates hinbekommen. Ich glaube, dass ich die templates explizit instan...t habe, und die dann als hunderte funktionen exportiert worden sind. Kann aber auch sein, dass ich soetwas verwechsle......
Aber export + implementation verbergen gibt es ja z.B. mit generics in .NET etc.
-
Generics werden auch zur Laufzeit und nicht zur Compilezeit ausgewertet.
-
Selbst wenn export funktioniert, dann muss man dennoch den Sourcecode der Templates hergeben - und genau das macht export sinnlos. Deshalb implementiert es niemand, weil es sowieso niemand nutzen würde. Es würde lediglich die Kompatibilität zu anderen Compilern brechen aber sonst keinen Vorteil bringen - bis auf eine sauberere Trennung von Definition <-> Implementierung.
Export ist nur dann interessant wenn ich dadurch keinen Sourcecode mehr hergeben muss. Das ist theoretisch möglich, praktisch aber noch ein paar Ecken schwerer als Export alleine.