🚀 go-pugleaf

Gerhard Traeger (gerhard@gt-priv.m.eunet.de) wrote:
> 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.

Es hat in C++ (genauso wie in C) noch nie ein Modulkonzept im Sinne des
Modulkonzepts von Modula 2/3 oder Ada gegeben. Die von Dir beschriebene
Trennung war keine (weil der Compiler sich nicht dafuer interessiert),
sondern wurde dem Programmierer mit Hilfe des Praeprozessors vorgegaukelt.

Aus dem Grund ist das was Du da vorbringst ein voellig konstruiertes
Argument. Was hindert Dich, Deine Implementation in ein .cc File zu
schreiben, und am Ende Deines Header Files ein #include "xxx.cc"
hinzuzufuegen? Wenn Du Code und Implementation in zwei verschiedenen Files
haben willst - bitteschoen, nichts hindert Dich daran.

> 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!

Wenn das so ist, dann muss es wohl an den 30000 Zeilen liegen, und nicht an
der Tatsache, dass der Compiler beim Uebersetzen den Code der Templates
sehen will. Bis auf die eben erwaehnte eine Zeile unterscheidet sich das
naemlich nicht von der zweiten Moeglichkeit, die Du aufgefuehrt hast.

[Cfront und Sun Loesung]
> 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.

Es ist ein Heidenaufwand notwendig, nur um eine Zeile im Header File zu
sparen. Natuerlich habe ich nichts gegen eine solche Loesung (wenn sie
funktioniert), ich frage mich jedoch, welchen Sinn es macht, diesen Aufwand
zu treiben, wenn das Resultat auch viel einfach zu haben ist. Daher auch
mein "ich kann keine Vorteile dieser Loesung erkennen". Wenn Du das
Einsparen der oben erwaehnten "#include..." Zeile als Vorteil ansiehst...
naja.

> 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?

Weil es in der Verantwortung des Programmierers (nicht des Schoepfers der
Library) liegt, wo welche Templates instantiiert werden. Wenn der das
vergisst oder aus Versehen zweimal durchfuehrt, dann geht die Suche los.

Wenn Du die explizite Instanzenbildung im Header File machst, dann wird
jedesmal eine Instanz erzeugt, wenn ein Modul von Dir dieses Header File
verwendet. Folgerichtig ist der Code mehrfach vorhanden und Du bekommst ein
"multiple definition" vom Linker. Wenn Du, um diesen Fehler zu umgehen dem
Linker beibringst, Templates zu erkennen und ueberfluessige Instanzen
rauszuschmeissen, dann wird Deine Loesung noch unsinniger, weil Du dann
genausogut dem Compiler sagen kannst, er solle alle Instanzen einfach
automatisch erzeugen (dazu braucht er dann eben die Definition), und Du
hast das, was Du als "Borland Methode" bezeichnest.

Gruss


        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com