🚀 go-pugleaf

Hi,
root (root@gt-priv.m.eunet.de) wrote:
: Wenn mich nicht alles taeuscht, ist die Frage nach dem richtigen Umgang mit
: template-member-Funktionen (tmf) die am haeufigsten gestellte und nie richtig
: beantwortete Frage. 

Ich kann nicht nachvollziehen, dass dies die am haeufigsten gestellte
Frage ist.  Obwohl die Frage in clc++m gelegentlich auftaucht, ist es
nicht so dass es uebermaessig viel gefragt wird. Derzeit erscheint mir
z.B. eher die Frage nach "renew" (in allen Variationen) deutlich
haeufiger zu sein...

: Ursache des Problems ist wohl, dass manche c++-Fans (leider auch die meisten 
: Compilerhersteller) meinen, der Compiler muesste so schlau sein, nur die tmf 
: Instanzen zu erzeugen, die tatsaechlich verwendet werden.

Das liegt vermutlich daran, dass eine Standard konforme C++
Implementation so schlau sein muss (OK, es gibt noch keine Standard,
aber diese Forderung wird mit ziemlicher Sicherheit im Standard
enthalten sein). Der Grund warum es derzeit keine Compiler gibt, der
Templates richtig behandelt liegt z.B. darin, dass die Definition von
Templates in ihrer jetztigen Form noch sehr jung ist. Aber ich bin mir
absolut sicher, dass sich die Compilerbauer den A**** aufreissen
werden, dem Standard zu genuegen und zwar so schnell wie irgend
moeglich! Der Markt fuer einen Standard konformen UND funktionsfaehigen
C++ Compiler ist gross. Sehr gross. Die Betonung liegt uebrigens
durchaus auf "funktionsfaehig" und gemeint ist nicht die Beschreibung,
in der der Compiler behauptet, was der Compiler kann!

: Dazu gibt es laut 
: g++-info (bestaetigt durch ein posting eines *borland.com und SUNs C++ 
: 4.0.1-Handbuch) zwei Ansaetze:
: 1. Borland-C++:
:    Template-Deklaration und -Definition in die header-Datei schreiben, ein
:    spezieller Linker filtert die entstandenen Redundanzen heraus.
:    Nachteil:
: 	Damit kann man das Konzept:
: 	- header-Datei = Schnittstellendeklaration,
: 	- Programm-Datei = Programmimplementation,
: 	endgueltig vergessen. Und damit auch die Wartung groesserer Projekte.

Zu fordern, dass es so gemacht wird, ist nicht Standard konform. Man
kann Deklaration und Definition von Templates trennen.

: 2. Cfront (AT&T, mit Einschraenkungen SUN C++):
:    Irgendwoher "weiss" der Compiler, wo die tmf definiert sind, bestimmt,
:    welche Instanzen notwendig sind und erzeugt diese.
:    Leider fehlt bei den meisten Rechnern die Einfuelloeffnung fuer Maggi.
:    SUN behilft sich mit TemplateDB-Verzeichnissen. Das scheint aber, wenn 
:    ueberhaupt, nur zu funktionieren, wenn
:    - header und source den gleichen Basisnamen haben und
:    - alle Quellen im gleichen Verzeichnis stehen.

Nein. Das ist nicht unbedingt noetig (zumindest nicht fuer den
generellen Ansatz; fuer die Implementation in SUN C++ schon...). Eine
Moeglichkeit, es so zu implementieren, dass man es auf beliebige Files
verteilen kann, besteht z.B. darin, aus den Files mit den Template
Source spezielle Objektfiles zu generieren, die Symbole enthalten, die
sagen, welche (Member-) Funktionen und Objekte definiert werden und wo
das entsprechende File steht. ggf. kann man auch eine Vorcompilierte
Fassung des entsprechenden Files Speichern.

: Bleibt als 3. Moeglichkeit die triviale Loesung der "expliziten 
: Instanzenbildung"

Es ist derzeit zwar womoeglich notwendig, dass es so gemacht wird, ist
aber keine "Loesung"!  Ein solcher Ansatz ist z.B. beim Arbeiten mit
STL irgendwo in der Groessenordnung von total unbrauchbar anzusetzen:
Ich verwende gelegentlich Klassen, deren Name, wenn ich alle Templates
ersetze (der Compiler ist bei Fehlermeldungen so freundlich, mir die
Arbeit abzunehmen :-), auf 1KB zugeht. ... und das sind noch nichtmal
"echte" Anwendungen! Niemand will sowas schreiben muessen. Ausserdem
ist das auch ein Maintainance-Problem: Aendere ich an der einen Stelle
einen Typ, aendern sich dutzende von anderen Typen.

:    - Waere dies die allgemein empfohlene, standardmaessig implementierte Art,
:      wuerde die Zahl der postings vom Typ "HELP: LINKER ERROR: UNDEFINED"
:      drastisch reduziert.

Ich empfehle, im Gegensatz zu dem Autor des urspruenglichen Artikels,
einen hypriden Ansatz, der sich z.B. mit g++ und SUN CC vertraegt: Man
schreibt Headerfiles fuer Templates wie die Headerfiles fuer andere
Klassen auch und included am Ende, abhaengig von einem Macro (z.B. fuer
SUN CC braucht man die Sourcen nicht zu includen), ggf.  die Datei, die
den selben Basisnamen wie das Headerfile hat, in der die entsprechenden
Template Funktionen/Objekte definiert werden. Das funktioniert
erstaunlich gut. Auch mit den derzeit verfuegbaren STL aehnlichen
Libraries. Einziger Haken: Die Executables werden teilweise elendig
gross.

:    - Die aus C uebernommenen Ansaetze, die Modularisierung in die
:      Dateistruktur abzubilden, bleiben erhalten.

Mit Standard konformen Compilern kommt das wieder...
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic