🚀 go-pugleaf

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) hat geschrieben:
>> 1. Borland-C++:
>>  ...
>> 	Damit kann man das Konzept:
>> 	- header-Datei = Schnittstellendeklaration,
>> 	- Programm-Datei = Programmimplementation,
>> 	endgueltig vergessen. Und damit auch die Wartung groesserer Projekte.
>Das ist nicht so schlimm, s.u.
>Dumm allerdings, wenn man Bibliotheken verkaufen will.
Oder wenn man bei der Suche nach der richtigen Schnittstelle nicht immer die
ganze Quelle durchstoebern will.
C erlaubt durch das header-Konzept immerhin die Trennung von Schnittstellen-
deklaration und Implementation. Die OOP-Unterstuetzung von C++ kann doch
wohl nicht bedeuten, dass ich selbst auf diesen bescheidenen Ansatz der 
Objektbildung verzichten muss.
Mein derzeitiges Lieblingsspielzeug hat ca. 30 000 dichtbeschriebene Zeilen
Quellcode. Wenn ich da alle template-member-Funktionsdefinitionen in die 
Header packen muss finde ich nichts mehr!

>> 2. Cfront (AT&T, mit Einschraenkungen SUN C++):
>Die Frage ist, welchen Vorteil diese Loesung bietet. Mir fallen auf Anhieb
>zwar einige kleinere, aber kein entscheidender Vorteil ein. Zudem ist die
>Loesung aufwendig in der Implementation.
Wenn es funktionieren wuerde, waere es ideal: man deklariert die templates
in einer header-Datei (inclusive inline-Funktionen), definiert die nicht-
inline-Funktionen in der zugehoerigen *.c-Datei und braucht sich bei der
Verwendung nur noch fuer die Information in der header-Datei interessieren.
Keinerlei Verwaltungsaufwand, Compiler und Linker sorgen fuer optimale
Instanzenbildung.


>> Bleibt als 3. Moeglichkeit die triviale Loesung der "expliziten 
>> Instanzenbildung"
>Dieser Weg ist fuer kleine Programme gangbar. Fuer groessere Projekte mit
>vielen Bibliotheken ist das praktisch nicht zu machen. Der Grund dafuer
>liegt darin, dass man beim Verwenden einer Klasse immer genau wissen
>muss, ob sich evtl. irgendwo in der Klassenhierarchie bis hinunter zur
>Basisklasse irgendwo ein Template befindet. Oder ob irgendeine Klasse, die
>man verwendet, vielleicht ein Objekt einer Template-Klasse oder einen
>Abkoemmling davon als (evtl. private) Data-Member hat. Das Verfahren setzt
>also eine Detail-Kenntnis der verwendeten Bibliotheken voraus, die weit
>ueber das hinausgeht, was man zum normalen "nur Benutzen" der Bibliotheken
>wissen muss.
>Verschaerfend kommt natuerlich noch der umgekehrte Effekt: Die explizite
>Instantiierung darf man nicht mehr als einmal machen, weil man sonst
>"multiple defines" bekommt. Das ist enorm umstaendlich, wenn man zu mehrt an
>einem Projekt arbeitet.
Ich bin zwar gegen lange Zitate, aber das hier verstehe ich komplett nicht.

Wie soll es zu "multiple defines" kommen, wenn die nicht-inline-template-
member-Funktionen genau einmal, naemlich beim Uebersetzen der Quelle, in
der sie stehen, fuer alle angeforderten Instanzen gebildet werden?

Wieso muss man hierbei wissen, wo sich in einer Klassenhierarchie ein
Template befindet? Nach meinem Wunsch (die explizite Instanzenbildung
im header mit der Deklaration, via "template class ...", anzuordnen und 
damit fuer den Verwender des headers sichtbar zu machen) ist es doch 
voellig egal, ob eine Klasse "selbstaendig", oder die Instanz eines 
templates ist! So wie es jetzt moeglich ist, mit "template class ..." 
in der Definitionsdatei, bekommt man eben erst beim linken eine saubere 
Fehlermeldung, die einem sagt, wo etwas zu tun ist.

Gerade wenn mehrere an einem Projekt arbeiten, ist die Borland-Methode nach
meinem Verstaendnis unhaltbar. Der Benutzer eines Programmes soll mit dessen
Implementation so wenig wie moeglich zu tun haben. Es kann aber durchaus 
sinnvoll sein, wenn nur die Instanzen eines Templates erlaubt sind,
die ihr Programmierer auch getestet hat!


MfG, Gerhard.