🚀 go-pugleaf

uz@wuschel.ibb.schwaben.com (Ullrich von Bassewitz) hat geschrieben:
>> Nein! Es ist eben, so wie ich es auch beschrieben hatte, genau der Schoepfer
>> der Library, der bei der "expliziten Instantiierung" festlegt, welche
>> Instanzen erzeugt werden! Und ich hatte auch versucht Dir zu erklaeren, dass
>> das bei groesseren Programmen eine notwendige Aufgabenteilung ist.
>
> Dann habe ich das wirklich nicht verstanden.
Grundprinzip: Arbeitsteilung.

> Du kannst mir ja nochmal erklaeren, wie denn derjenige, der eine Bibliothek
> schreibt von vorneherein wissen kann
Nicht von vorneherein, sondern aus seinem Lastenheft. Bei einer normalen
Funktionen-Bibliothek stellt sich diese Frage doch auch (nicht).

> mit welchen Argumenten seine Templates instantiiert werden.
Weil er es selber tut. Templates degenerieren damit zu einer Zusammenfassung
einer endlichen Zahl von Klassen. Die nicht-inline-Template-Member-Funktionen
um die es hier geht, sind dann als ganz normale Funktionen zu betrachten,
die in der Quelle lediglich etwas komprimiert geschrieben wurden. Zumindest
g++2.7.2 und SUN C++ 4.0.1 vertragen es uebrigens auch, wenn man (z.B. wegen 
Eigenheiten einzelner Argument-Typen) Template-Member-Funktionen fuer
spezielle Typen als eigenstaendige Funktionen codiert.

> Wenn er das nicht weiss, wie soll dann eine explizite Instantiierung
> in der Bibliothek funktionieren?
Da er das weiss, gibt es dieses Problem nicht. Falls Du Schwierigkeiten hast,
zu verstehen, warum er das meist weiss: Matrix-Operationen lassen sich
wunderbar mit Templates implementieren, aber was ist bitte die Inverse
einer String-Matrix? 
Wie Du Dir sicher vorstellen kannst, sind die wenigsten Programmierer damit 
beschaeftigt, zum x-ten Mal die STL (oder andere Standardbibliotheken mit
Standardtypen) zu implementieren. Je spezieller die Funktionen werden, desto
groesser wird auch die Wahrscheinlichkeit, dass der zulaessige/sinnvolle
Parameterraum der Template-Argumente recht uebersichtlich bleibt.

MfG, Gerhard