wofür templates?
-
Bisher habe ich noch keinen Begriff geprägt. Und eine Mode konnte ich bisher auch noch nicht etablieren.
Und was meinst du mit mithalten? Ist das hier für dich irgendwie ein persönlicher wettstreit?Ne. Du verwirrst mich nur mit den 10000 Paradigmen die du benennst. Da muss ich doch zurückflamen!
bezog sich nicht auf dich.
Meine Erfahrung ist nur, dass Template-Wissen noch nicht so verbreitet ist. Ein gutes Beispiel ist z.B. der wirklich schlechte c't-Artikel "Generische Programmierung für bessere Wiederverwendbarkeit" von Dr. Markus Mohnen.Gut. Denn ich weiß wie man C++ templates wirklich benutzt. Nur manchmal ist normale Polymoprhie eben geeigneter. Und in meinem aktuellen Code bevorzuge ich eben diese Polymorphie. (Der Code ist übrigens in höchstem Maße rekursiv *g*)
-
Ich liebe Templates, und verwende sie eigentlich ganz gern. Ok - es ist auch nicht alles Template bei mir. Muß auch nicht, nur wenn ich sie für Sinnvoll erachte.
Das war vor einem Jahr auch noch nicht so, aber z.B. Singletons ohne Template? Nein Danke.
Mathe stuff, wie Vector und Matrix -> Template, schon weil dieses Unroll the Loop da ohne Problem vom Compiler erledigt wird. Dazu noch Template Metaprogramming.
Handles? Na Template, weil sie sonst nicht Typesafe sind. Ich möchte nicht für Texture und Particle ... einen eigenen Handle Manager und Handle Code schreiben. Da ist doch Handle< SingleTexture > oder so besser.
Naja - es gibt noch 100 Nützliche Beispiele.
P.s. Mr N - das von Humme war sicher kein Angriff auf dich. Du brauchst also nicht zurückflamen. Außerdem hat er doch keine komischen Modebegriffe verwendet.
-
Ich liebe Templates, und verwende sie eigentlich ganz gern. Ok - es ist auch nicht alles Template bei mir. Muß auch nicht, nur wenn ich sie für Sinnvoll erachte.
Das war vor einem Jahr auch noch nicht so, aber z.B. Singletons ohne Template? Nein Danke.
Mathe stuff, wie Vector und Matrix -> Template, schon weil dieses Unroll the Loop da ohne Problem vom Compiler erledigt wird. Dazu noch Template Metaprogramming.
Handles? Na Template, weil sie sonst nicht Typesafe sind. Ich möchte nicht für Texture und Particle ... einen eigenen Handle Manager und Handle Code schreiben. Da ist doch Handle< SingleTexture > oder so besser.
Naja - es gibt noch 100 Nützliche Beispiele.
Ich mag templates auch.
P.s. Mr N - das von Humme war sicher kein Angriff auf dich. Du brauchst also nicht zurückflamen. Außerdem hat er doch keine komischen Modebegriffe verwendet.
Meine Worte heißen nicht immer das wörtlich. using MrN::decrypt; kann ich dir nur empfehlen ;)!
-
also den humor von Mr. N habe ich leider nicht verstanden, und wenn es kein humor gewesen sein soll, dann hab ichs noch weniger verstanden.
ich muss sagen das ich mit templates auch noch nicht viel gemacht habe, eigentlich nur da wo die aufgabenstellung in meinem studium es direkt geforder haten. ich denke das sie ja nuetzlich sein moegen, aber doch, zumindestens da wo es moeglich ist, durch das verwenden von polymorphie abgeloest werden, da man diese in jeder Objekt orientierten sprache verwenden kann, was bei templates ja nicht der fall ist.
wenn also jemand als erstes java lerrnt ist er es gewohnt alles in klassen zu stecken, nicht in templateklassen. und wird dies wohl aus gewohnheit bei sprachen die mehr moeglichkeiten bereitstellen verwenden.
-
Kann man Templates eigentlich nicht fast immer mit OOP ersetzen? Ich kenn mich nicht wirklich mit Templates aus (nur das Grundlegende) , aber zum Beispiel bei Container-Klassen wie Vector kann man ja anstatt das ganze zu templatisieren, auch einfach ein Objekt einer Wurzelklasse als Elementtyp verwenden, in das Objekte von Subklassen dann auch reinpassen (wenn es eine Basis-Wurzel für alle Klassen gibt und die Sprache reinobjektorientiert ist, kann man dann alles in den Vecotr reintun) Naja, was ich mal von den Template-Freaks gern wissen würd, was (konkret) kann man wirklich nur mit Templates machen, was nicht durch OOP ersetzbar wäre (wenn die Sprache reinobjektorientiert ist und keinerlei primitive Datentypen hat) ?
-
Also man kann Template-Rekursionen machen die allerdings je nach Tiefe sehr viel Compilerzeit in Anspruch nehmen. Desweiteren braucht man Templates wenn man eine Klasse hat aber eigentlich viele Klassen mit der selben Funktionalität für verschiedene Typen etc. braucht...
Bsp: Matrix<int>, Matrix<string>, matrix<char> werden vom Compiler wie 3 verschiedene Klassen behandelt. In wirklichkeit wurde Matrix aber nur einmal mit Hilfe eines Templates implementiert und kann für alle Typen von Objekten verwendet werden (die Programmdatei wird dementsprechend größer)
-
Die Klasse string z.B. ist ein typedef auf:
basic_string<char, char_traits<char>, allocator<char>>
-
[ Dieser Beitrag wurde am 03.06.2003 um 11:27 Uhr von TS++ editiert. ]
-
Auch interessant ist sowas:
template<int i, int j> struct max { enum { ret = i > j ? i : j }; }; template<int i, int j, int k> struct max3 { enum { ret = max<max<i, j>::ret, k>::ret }; }; template<class T, int i> class fixed_vector { T p[i]; public: T &operator[](int x) { return p[x]; } T operator[] (int x) const { return p[x]; } } struct X { enum _type { Int, Double, Fixed_vector } type; union { int *a; double *b; fixed_vector<int, 4> *c; } x; char z[max3<sizeof(int), sizeof(double), sizeof(fixed_vector<int, 4> )>::ret]; X(_type x) : type(x) { switch (x) { case Int: x.a = z; new(a) int; break; case Double: x.b = z; new(b) double; break; case Fixed_vector: x.c = z; new(c) fixed_vector<int, 4>; break; } } ~X() { if (type == Fixed_vector) x.c->~fixed_vector(); } }EDIT: const an der falschen stelle
EDIT 2: verdeutlichung des anwendungsgebietes
(kein Anspruch auf Richtigkeit)[ Dieser Beitrag wurde am 03.06.2003 um 12:11 Uhr von Mr. N editiert. ]
-
PS: Wer Placement-new verwendet, muss auch den Destruktor aufrufen.
-
Original erstellt von crass:
Kann man Templates eigentlich nicht fast immer mit OOP ersetzen? Ich kenn mich nicht wirklich mit Templates aus (nur das Grundlegende) , aber zum Beispiel bei Container-Klassen wie Vector kann man ja anstatt das ganze zu templatisieren, auch einfach ein Objekt einer Wurzelklasse als Elementtyp verwenden,Kann man.
Aber der Haken ist der, daß dadurch eine gemeinsame Basisklasse (a la "Object") geschaffen wird, die Klassenhierarchien miteinander verbindet, obwohl diese eigentlich keinen Zusammenhang haben.
Bei Templates wird zwischen den verschiedenen Klassen aber streng unterschieden, sie sind nämlich _nicht_ im OO Sinne verwandt.
Stichwort wäre also eher "Vermeidung von Modellverschmutzung".
-
Das würde ich niemals bezweifeln. Allerdings versuche ich *jeden* Tag mir ein winzig kleines bischen mehr Wissen anzueignen. Dabei stolpere ich dann häufig über sehr interessante Ideen die hier dann lustigerweise einfach als "Modewörter" abgetan werden ohne das sich derjenige die Mühe macht sich wenigstens mal zu informieren.
Ich bin wirklich lieber jemand der keine Ahnung hat, das weiß und versucht dies Stück für Stück zu ändern, als jemand der meint er hätte schon alles gesehen und alles was er nicht kennt als schwachsinn abtut.
hehe, sehr gut ausgedrueckt!Also ich wuerd liebend gern dein "Unwissen" ueber C++ haben Hume.
mfg
v R
-
@marc++us
also ich find das eigentlich keine Modellverschmutzung. Macht doch Sinn alle Klassen von einer gemeinsamen Wurzel abzuleiten.. der Vererbungstest mit "is a" klappt doch auch wunderbar auf eine Klasse "Object" ... Auto ist ein Objekt, Window ist ein Objekt, Vogel ist ein Objekt... passt doch!edit: ach so, ich glaub ich hatte dich falsch verstanden, du meinst man kann in einen Vector dann Objekte von allen möglichen Klassen reintun, die überhaupt nix miteinander zu tun haben.. das liegt natürlich dann beim Programmierer das zu vermeiden und is natürlich nicht so typsicher wie mit Templates.
[ Dieser Beitrag wurde am 03.06.2003 um 13:23 Uhr von crass editiert. ]
[ Dieser Beitrag wurde am 03.06.2003 um 13:27 Uhr von crass editiert. ]
-
Also, das mit der Typsicherheit hast Du schon richtig interpretiert.
Aber auch der andere Fall ist nicht so ohne... da C++ Mehrfachvererbung erlaubt, ist es nicht unproblematisch alle Objekte von "object" abzuleiten.
Und lustig ist das aus OO-Sicht auch, weil man überall bei Büchern zur OOA lesen kann, daß man eben _keine_ Selbstzweckvererbungen einführen soll, nur um Code zu sparen oder um Gemeinsamkeiten herauszustellen. Im Klartext: Vererbungen sollen dort auftreten, wo sie auch natürlicher Teil des Modells sind und keine zusätzlichen Abstraktionsebenen einführen. Also: Auto und Vogel haben keine gemeinsame Basisklasse, weil sie Objekte sind. Hier ist die Abstraktion zu weit getrieben. Sagt die OO-Literatur. Um aus diesem Dilemma herauszukommen, muß man die gemeinsame object-Oberklasse zu einem "Implementierungsdetail der Zielsprache" erklären... bißchen fragwürdig in meinen Augen. Ähnlich lösen das auch die UML-Tools, man zeichnet alle Abhängigkeiten und Vererbungen der Objekte ein, nur die Vererbung von object wird nicht gezeichnet, "weil die ja sowieso da ist". Würde man sie einzeichnen, wäre das Modell immer global zusammenhängen und es gäbe keine Objektfamilien und Inseln, wie es ja eigentlich Ziel der Modellierung war diese zu gewinnen.
Templates lösen diese Sache in C++ eindeutig auf - ich kann in verschiedenen Themeninseln meines Modells auf die gleiche Template-Klasse zurückgreifen, ohne daß ich die Klassen der Themeninseln miteinander in Bezug setze. Das hat schon viele Vorteile.
@<-> Hinweis zu Templates und Spielen
In http://www.c-plusplus.net/titelanzeige.php?ISBN=3826609239 haben die Autoren den Themen "Spiele und STL" sowie "C++, Templates und Programmgeschwindigkeit" eigene Abschnitte gewidmet.
-
Marcus: Du vermischst die Ebenen. Du kannst in der OOA jedes Modell der Welt aufstellen, ohne die Programmiersprache zu berücksichtigen. Wie du das ganze dann implementierst, dh ob du Rücksicht auf eine evtl. vorhandene absolute Oberklasse nehmen mußt oder nicht, ist Gegenstand der OOP, und berührt dein OOA-Modell in keinster Weise.
-
Wer unterscheidet denn tatsächlich zwischen OOA-Vererbung und OOP-Vererbung? Das wird häufig als eine einzige Sache betrachtet.
Die Ebenen treten nicht getrennt auf, sondern vermischt. Vor allem weil die Denkrichtung aus der Seite der Praktiker kommt... der OOPler denkt in Modellkategorien. Die Implementationssprache prägt das Bild des höheren Modells (auch wenn das natürlich nicht so sein sollte). Betrachtest Du nachher OOA-Modelle, so sieht man dann dann deutlich die Auswirkungen der OOP-Sprachen im Modell. Das ist nicht rückwirkungsfrei.
-
Original erstellt von Marc++us:
Wer unterscheidet denn tatsächlich zwischen OOA-Vererbung und OOP-Vererbung? Das wird häufig als eine einzige Sache betrachtet.Anscheinend jeder Java-, Eiffel- oder Smalltalk-Programmierer. Denn die haben alle überhaupt kein Problem damit, dass alle Klassen von Object, ANY oder weiß-nicht abgeleitet sind, während diese Klassen in ihrer Analyse überhaupt nicht vorkommen.
-
Daß die genannte Zielgruppe wohl durchaus Verständnisprobleme damit hat sieht man an "Wofür Templates" und "ein Auto ist ein Objekt, ein Vogel ist ein Objekt".
-
Original erstellt von Marc++us:
Daß die genannte Zielgruppe wohl durchaus Verständnisprobleme damit hat sieht man an "Wofür Templates"Smalltalk hat dynamische Typen und braucht sowas nicht, Eiffel hat Templates, Java wird sie haben.
und "ein Auto ist ein Objekt, ein Vogel ist ein Objekt".
Dass die genannten Gruppen kein Problem mit einer gemeinsamen Oberklasse haben, wird dadurch widerlegt, dass sie gemeinsame Oberklassen benutzen? Wow, tolle Argumentation.
-
und "ein Auto ist ein Objekt, ein Vogel ist ein Objekt".
Dass die genannten Gruppen kein Problem mit einer gemeinsamen Oberklasse haben, wird dadurch widerlegt, dass sie gemeinsame Oberklassen benutzen? Wow, tolle Argumentation.Nein. Es geht nicht ums Benutzen, was lediglch pragmatisch ist, sondern darum, dass es hier so gerechtfertigt wird.
Und lustig ist das aus OO-Sicht auch, weil man überall bei Büchern zur OOA lesen kann, daß man eben _keine_ Selbstzweckvererbungen einführen soll, nur um Code zu sparen oder um Gemeinsamkeiten herauszustellen.
Nur ist es dann schwer irgendeinen Sinn in privater Vererbung, wie sie in C++ möglich ist, zu finden.
Meine Erfahrung ist nur, dass Template-Wissen noch nicht so verbreitet ist. Ein gutes Beispiel ist z.B. der wirklich schlechte c't-Artikel "Generische Programmierung für bessere Wiederverwendbarkeit" von Dr. Markus Mohnen.
Der Artikel war wirklich nicht grade toll. Aber in der nächsten c't hagelte es ja auch Leserbrife. Allerdings fand ich die Java-Erweiterungen an sich interesant, von denen icch ohne diesen Artikel nichts gewust hätte.