wofür templates?

HumeSikkins

Templates helfen bei geschicktem Einsatz die Anzahl der Ableitungen zu reduzieren, weil man gemeinsame Eigenschaften nicht über eine Ableitung, sondern eine Template-Instanziierung realisieren kann.

Gleichzeitig reduzieren Templates dabei die enstehenden Abhängigkeiten, weil gemeinsame Eigenschaften nicht über Vererbung (nach friend die zweitstärkste Abhängigkeit in C++) sondern nur über einen Namen ausgedrückt werden.
Dies spielt allerdings natürlich nur in so statischen Sprachen wie C++ eine Rolle.

Du verlierst die Laufzeittypprüfung.

Oha. Das habe ich in der Tat übersehen.

HumeSikkins

Templates sind imo einfach keine elegante, "natürliche" Programmier-Technik

Wie definierst du elegant und "natürlich"? Ist OOP für dich natürlich und elegant? Wenn ja, schau mal nach comp.object. Selbst dort findest du viele Leute die anderer Meinung sind. Oder was ist mit komplett anderen Ansätzen wie z.B. der hinter Prolog?

crass

jo, OO halt ich für "natürlich"...damit mein ich eine Technik, die dem menschlichen Denken nahe liegt.. Menschen stellen sich würd ich mal sagen, normalerweise alles irgendwie als Objekt (Sache) vor, auch Verallgemeinerungen und Konkretisierungen (wie bei Vererbungen) von Dingen und Personen sind typisch fürs normale Denken

Prolog kenn ich nicht? Hab ich da was verpasst?

Bashar

Original erstellt von kingruedi:
**Man sollte die abhängigkeiten zwischen den Klassen möglichst reduzieren. [...]

Ich denke nicht, dass ein Auto und ein Vogel eine Verwandschaft haben sollten, selbst wenn beide irgend wo ein gleichen Member enthalten.**

Das Argument kann ich nicht gelten lassen. Inwiefern sind denn Auto und Vogel mehr miteinander verwandt, wenn sie von einer gemeinsamen Basisklasse abgeleitet sind? -- Nicht im geringsten. Beide Klassen sind abhängig von Object, was aber nicht weiter tragisch ist, weil Object fest ist, aber nicht voneinander.

Daniel E.

Original erstellt von crass:
jo, OO halt ich für "natürlich"...damit mein ich eine Technik, die dem menschlichen Denken nahe liegt.. Menschen stellen sich würd ich mal sagen, normalerweise alles irgendwie als Objekt (Sache) vor, auch Verallgemeinerungen und Konkretisierungen (wie bei Vererbungen) von Dingen und Personen sind typisch fürs normale Denken

Plato hat das auch erzählt ... Verwunderlich ist nur, wieso niemand wirklich den Durchblick hat, was Objektorientierung denn bedeutet. Und jeder irgendwas anders versteht (wie dieser Thread ja auch zeigt).

Prolog kenn ich nicht? Hab ich da was verpasst?

Ja.

Marc++us: Würde man nun sagen, dass die 'Ableitung von Object' keine 'Ableitung im Sinne des Entwurfes', sondern nur 'irgendwas' ist, dann wärest Du zufrieden? Wenn ich deine Kritik auf ihren Kern reduziere, dann sagt Du schließlich (simplifiziert), dass der Vorteil von Templates darin liegt, dass es im OOA nicht äquivalentes gibt, und somit keine Begriffe verwischt werden können. Das wundert kaum, weil Templates sind nur eine edle Form von Makros.

HumeSikkins

Menschen stellen sich würd ich mal sagen, normalerweise alles irgendwie als Objekt (Sache) vor, auch Verallgemeinerungen und Konkretisierungen (wie bei Vererbungen) von Dingen und Personen sind typisch fürs normale Denken

Das halte ich für quatsch. Es gibt mindestens genausoviele Menschen die sich mit Entitäten und Relationen viel leichter tun. Es gibt nicht *das* Modell für das *natürliche* Denken. Es gibt unzählige Modelle die in bestimmten Situationen mehr oder weniger gut passen.

Prolog kenn ich nicht? Hab ich da was verpasst?

Definitiv. Ob man Prolog nun mag oder nicht (ich bin zu blöd dafür), es erweitert auf jeden Fall den Horizont. Es gibt deutlich mehr als nur C++, Java oder Pascal.

Zum Thema single-rooted-hierarchy:
Templates und eine single-rooted hierarchy schließen sich doch nicht gegenseitig aus. Es ist doch nur so, dass man in einer Sprache die nicht rein OO ist und die Templates unterstützt keinen wirklichen Grund für eine allgemeine Basisklasse Objek hat (ich sehe zumindest keinen).
In einer solchen Sprache gibt es andere Möglichkeiten neben Vererbung um sein Programm zu strukturieren.

HumeSikkins

Das wundert kaum, weil Templates sind nur eine edle Form von Makros.

Kannst du mir das genauer erklären? Meinst du mit Makros so Präprozessor-Dinge wie man sie bereits aus C kennt? Wenn ja, dann sehe ich nämlich nicht, warum Templates (die ja vollkommen in die Sprache integriert sind und auf vielfältige Weise mit anderen Sprachmitteln interagieren) nur eine edle Form von Makros sind bzw. warum dass dann für z.B. Vererbung nicht gelten sollte?

"... edle Form von Makros ... "
wahrscheinlich, weil sie vor laufzeit aufgelöst werden

Bashar

Hatten wir das nicht schonmal?

IMHO sind Templates ein Spezialfall von Makros und keine "edle" Form, aber darum gehts ja nicht. Makro ist dabei nicht im cpp-Sinne zu verstehen.

... hatten wir das schonmal?

Original erstellt von Bashar:
ein Spezialfall

edel, weil rekursiv

HumeSikkins

Hatten wir das nicht schonmal?

Wenn du das sagst, bestimmt. Ich kann mich dummerweise nicht daran erinnern und eine Suche war bisher auch nicht erfolgreich.

IMHO sind Templates ein Spezialfall von Makros und keine "edle" Form, aber darum gehts ja nicht.

Wo ist der Unterschied? Und was macht sie zum Spezialfall?

Makro ist dabei nicht im cpp-Sinne zu verstehen.

Ok. Was sind dann Makros? Ich kenne den Begriff nur in zwei Versionen:
a) Blöcke dir durch reine Textersetzung zu Ziel-Sprachkonstrukten umgewandelt werden (-> C-Makros)
b) Ansammlung von einfachen Befehlen die nach einander abgearbeitet werden (-> Makros in GUI-Umgebungen oder Makro im Sine von Makro-Command).

Da muss es ja sicher noch mindestens ein c) geben.

Also, falls jemand Zeit und Lust hat, ich würde mich über ein paar erklärende Sätze freuen.

[ Dieser Beitrag wurde am 04.06.2003 um 07:24 Uhr von HumeSikkins editiert. ]

Spacelord

Also ich lehn mich jetzt mal ganz weit aus dem Fenster und behaupte,wenn ich in Java nen Vector nutze der alle Subtypen von Object speichert muss ich zur Laufzeit in allen Methoden,die Elemente des Vectors nutzen wollen,Fallunterscheidungen einfügen um sicherzustellen,dass das Object-Objekt ,das ich aus dem Vector auslese,auch von der "passenden" Methode weiterverarbeitet wird um böse Laufzeitfehler zu vermeiden.Weiter behaupte ich mal dass einer der Vorteile der OOP darin liegt diese Fallunterscheidungen durch dynamische Typenprüfung überflüssig zu machen.
Wenn ich also ohnehin prüfen muss,ob das ausgelesene Object-Objekt nun vom Subtyp A,B oder C ist,kann ich das Ganze auch gleich in C schreiben.

Vielleicht bin ich ja auch im falschen Film,aber ich denke schon das Templates eine gewisse Arbeitserleichterung darstellen und die Jungs bei sun werden schon wissen warum sie es für nötig halten ihre Sprache damit zu erweitern .

MfG Spacelord

Bashar

Original erstellt von HumeSikkins:
Hatten wir das nicht schonmal?**
Wenn du das sagst, bestimmt. Ich kann mich dummerweise nicht daran erinnern und eine Suche war bisher auch nicht erfolgreich.**

Vielleicht vor nem Jahr, oder etwas mehr ... Makro deshalb, weil *im wesentlichen* nichts anderes passiert, als dass die Parameter eingesetzt werden (von Sachen wie Spezialisierung und speziellen Lookup-Regeln abgesehen). Spezialfall deshalb, weil die Möglichkeiten der Code-Transformation doch sehr begrenzt sind.

**
Ok. Was sind dann Makros? Ich kenne den Begriff nur in zwei Versionen:
a) Blöcke dir durch reine Textersetzung zu Ziel-Sprachkonstrukten umgewandelt werden (-> C-Makros)
**

Syntaktisch zusammenhängende Blöcke, die durch beliebige Verarbeitung zu Ziel-Sprachkonstrukten umgewandelt werden, auf Syntaxbaum-Ebene.

-> Lisp-Makros

[ Dieser Beitrag wurde am 04.06.2003 um 09:00 Uhr von Bashar editiert. ]

Bashar

Original erstellt von Spacelord:
Also ich lehn mich jetzt mal ganz weit aus dem Fenster

Etwas zu weit, würde ich meinen

**
und behaupte,wenn ich in Java nen Vector nutze der alle Subtypen von Object speichert muss ich zur Laufzeit in allen Methoden,die Elemente des Vectors nutzen wollen,Fallunterscheidungen einfügen um sicherzustellen,dass das Object-Objekt ,das ich aus dem Vector auslese,auch von der "passenden" Methode weiterverarbeitet wird um böse Laufzeitfehler zu vermeiden.**

Unsinn.

Weiter behaupte ich mal dass einer der Vorteile der OOP darin liegt diese Fallunterscheidungen durch dynamische Typenprüfung überflüssig zu machen.

Und jetzt willst du behaupten ausgerechnet Java würde dynamische Typprüfung nicht können? War wohl nix.

Spacelord

Unsinn???
Naja,vielleicht hast du ja nen anderes Java aber wenn ich bei mir versuche aus einem Object-objekt z.B das Attribut Bremsweg meines Auto-objekts(das in dem Object vector gespeichert war)auszulesen schmiert mir das Programm ab.
Wenn du nicht prüfen musst ob das Object-objekt dass dir der Vector liefert ein Auto oder ein Bananen Objekt ist bin ich ja beruhigt.

MfG Spacelord

Bashar

Du castest das Objekt in die Klasse, die du meinst, die es hat, und gut. Ne Fallunterscheidung gibts da nicht. Höchstens nen Fehler, der von dem zu verantworten ist, der das Objekt in den Vektor gesteckt hat.

Spacelord

Das ist ja der Punkt,du weisst ja nicht welche Klasse es hat also kannst du für alle möglichen Fälle ne instanceof Abfrage machen.
Wenn du die Objekte aus dem Vektor z.B als Parameter für ne Methode nutzen möchtest musst du doch erstmal sicherstellen das deine aktuellen Parameter mit der richtigen Methode verarbeitet werden,und hin ist die Dynamik.

@Spacelord: Antwort

crass

@spacelord
in einen java-Vector tut man normalerweise nur Objete eines bestimmtes Typs rein und weiß dann ja auch wie man casten muß..

Vector autos= new Vector();
Auto bmw= new Auto("BMW");
autos.addElement(bmw);
Auto car= (Auto) autos.get(0);  //casten und fertig, wenn der Cast bei Laufzeit
                                //schief läuft, weiß man das was nich stimmt

[ Dieser Beitrag wurde am 04.06.2003 um 10:27 Uhr von crass editiert. ]