Performancemythen?

Gregor

asc schrieb:

Weshalb ich auf den Code rumreite kann ich auch gerne sagen: Ich habe schon mal die "Demonstration" gesehen das Java fast genauso schnell wie C++ ist. Die Demonstration war sehr interessant und zeigt, das Verlage wie z.B. heise (war ein Artikel aus der ct oder ix) auch schlechte Artikel verfassen. Auf Javaseite hat man optimiert, auf C++ Seite hat man eine stupide Lösung hingeschrieben die jeder der wenigstens etwas C++ Ahnung besitzt, besser hätte machen können (Ich sag nur sowas wie Wertübergaben kontra Referenzübergaben...).

An den Artikel erinnere ich mich auch. Ich kann Dir da aber nur halb Recht geben. Der Autor hatte offensichtlich kein besonders tiefgehendes Verständnis von C++, das sehe ich auch so. In dem C++ Code hätte man eine ganze Menge besser machen können. Aber was die C++-Seite bei diesem Artikel gerne übersieht, ist die Tatsache, dass der Javacode auch nicht gerade optimiert war. Da wurde auch ne ganze Menge Mist gebaut. Ich erinnere mich daran, dass da an irgendeiner Stelle ein String statt einem StringBuffer oder einem StringBuilder genutzt wurde, was an der entsprechenden Stelle zu einem sehr großen Unterschied geführt hat. Der Autor wollte damals glaube ich C# als die tolle, neue Sprache von MS darstellen. Und C# wird auch genau sein Hintergrund gewesen sein.

Ein weiterer Punkt bezüglich dieses Artikels ist allerdings, dass C++ im Vergleich zu Java oder C# deutlich mehr Verständnis erfordert, um damit akzeptablen Code prduzieren zu können. Man kann da in viel mehr "Performancefallen" und auch "Designfallen" hineinlaufen. Diesbezüglich sollte man sich die Frage stellen, wie realistisch perfekter Code in einem Projekt ist. Vielleicht ist es gar nicht so unrealistisch, anzunehmen, dass Leute kein wirklich tiefgehendes Verständnis der genutzten Programmiersprache und der Funktionsweise von Computern im Allgemeinen haben.

Jester

Xin schrieb:

Obwohl Jesters Behauptung, ich hätte eine Aussage gemacht, die aufgrund ihrer Allgemeinheit falsch wäre, sich zum Glück nicht bewahrheitete.

Doch, natürlich. Du redest von OOP und tätigst aussagen, die nur nach Deiner Definition zutreffen, für die normale Definition aber falsch sind. (Siehe auch nochmal das 2+2-Beispiel oder mach 1+1 draus, wenn das einfacher ist ;)).

Ich habe nichts erfunden, ich spreche von OOP.

Aber nicht in der Standardbedeutung. Das wovon Du redest ist demnach nicht OOP, weil OOP eben schon eine andere Definition hat. Und nein, wir nennen Deine Birne jetzt nicht Apfel!

Jester schrieb:

Dann könnten wir da auch mal vernünftig drüber reden (wobei mich's ehrlich gesagt nicht sooo brennend interessiert, ...).

Du hast Dich hiermit als Diplom Informatiker entsprechend meiner Umfrage qualifiziert.

Danke, aber das ist nicht nötig -- ich kann meine Qualifikation bereits anderweitig nachweisen.
Mich betrifft das Thema übrigens nur sehr sekundär (Informatiker müssen ja wie wir wissen nicht automatisch Software entwickeln). Ich beschäftige mich in erster Linie mit anderen Dingen. Warum sollte ich mich jetzt also so brennend dafür interessieren? Bloß weil Du irgendwas abgelassen hast? Ich sehe hier ehrlich gesagt nicht die Chance viel neues zu lernen.

Jester

Gregor schrieb:

Aber was die C++-Seite bei diesem Artikel gerne übersieht, ist die Tatsache, dass der Javacode auch nicht gerade optimiert war.

Das stimmt zwar, aber die da Strings in Java ja nie by-value übergeben werden, war wenigstens dieses Problem im Java-Code ausgeschlossen. -- Und das waren ne Menge Aufrufe.

Klar, man mag jetzt sagen, dass C++ halt schwieriger ist (so hieß es doch damals nach Beschwerden auch: "mag ja sein, aber Java macht sowas halt automatisch"), aber das sind nunmal absolute Basics. Die müssen sein. Wenn man das nicht kann, dann darf man halt auch keinen Vergleich machen.

edit: C++ hatte zusätzlich noch das Problem, dass immer sowas wie x = x + ... dastand. Daraus ein += zu machen brachte auch einiges. Das dürfte durchaus in ne ähnliche Kategorie fallen wie der StringBuffer-Fehler.

DEvent

Er ist Student, er darf noch Fehler machen. Der Umkehrschluss bedeutet ja nicht, dass Studenten alles falsch machen.
In die Frage der Komplexität habe ich mich nirgendwo eingemischt, weil sie nichts mit dem Thema zu tun hat. n ist konstant, da es sich um den identischen Algorithmus handelt, und k nervt den Anwender, mehr gibt's dazu nicht zu sagen.

Yo lassen wir das, ich geb mich geschlagen. Gibt halt 2 Typen von Programmiern, den einen ist das k egal, weil die schreiben lieber schneller Programme, die portabel sind und lassen das k den Compilerschreibern. Die zweite Sorte investiert Jahre der Forschung um das k gegen Null zu bekommen und wundert sich wieso keiner ihre Programme verwendet (es seih den sie sind zufaellig Compilerschreiber).

Danke, ich kann wohl doch besser JavaScript als du
So ein Ansatz macht aber 0 Sinn - allein der Vorschlag ist lächerlich.

Weißt du was Prototype Sprachen sind?

Warum ist Vererbung besser als das Prototype basierte Objekt klonen?

Habe ich nicht vorhin ein Beispiel fuer Vererbung bei JS geschrieben?

function Basisklasse(eigenschaft)
{
    this.eigenschaft = eigenschaft;
    this.macheWas = basisklasseMacheWas;
}

function basisklasseMacheWas()
{
    alert(this.eigenschaft);
}

function Katze(eigenschaft)
{
    this.constructor(eigenschaft);
    this.macheWas = new function()
        {
            alert("katze hat: " + this.eigenschaft);
        }
}
Katze.prototype = new Basisklasse();

katze = new Katze("Beine");

Ist das keine Vererbung?

asc

Jester schrieb:

edit: C++ hatte zusätzlich noch das Problem, dass immer sowas wie x = x + ... dastand. Daraus ein += zu machen brachte auch einiges. Das dürfte durchaus in ne ähnliche Kategorie fallen wie der StringBuffer-Fehler.

Mal davon Abgesehen das auch in C++ das "StringBuffer"-Problem bestand. Den bei vielen Stringadditionen nutzt man auch unter C++ eher ein entsprechendes Streamobjekt.

Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.

cu André

Jester

DEvent schrieb:

Yo lassen wir das, ich geb mich geschlagen. Gibt halt 2 Typen von Programmiern, den einen ist das k egal, weil die schreiben lieber schneller Programme, die portabel sind und lassen das k den Compilerschreibern. Die zweite Sorte investiert Jahre der Forschung um das k gegen Null zu bekommen und wundert sich wieso keiner ihre Programme verwendet.

Du hast es immer noch nicht verstanden. Aber vielleicht erklärst Du mir mal, warum immer noch zur linearen Optimierung der Simplex-Algorithmus (exponentielle Laufzeit) verwendet wird, obwohl es Algorithmen mit polynomialer Laufzeit gibt? Woran könnte das denn liegen?

Es geht nicht darum nur noch das k zu betrachten. Aber in der Realität das k vollständig außen vorzulassen ist realitätsfern (zumal es im betrachteten Fall ja um einen Faktor k, keine additive Konstante ging). In manchen Fällen ist auf Grund der großen Konstanten tatsächlich ein theoretisch schnelleres Verfahren in der Praxis langsamer. Zudem kann man auch wenn man einen tollen Algorithmus implementiert durch geschickte Datenstrukturen oft noch einen Faktor 10 oder mehr rausholen. Das zu ignorieren wäre doch doof. Wie gesagt, es macht den Unterschied zwischen 10s und 100s Berechnung. Während das eine noch gut geht ist das andere schon am Rande des erträglichen für den interaktiven Betrieb.

Aber wenn Du weiterdiskutieren willst, dann schreib doch mal ausführlich Deine Kritikpunkte an meinen Aussagen. Bitte hebe dabei insbesondere hervor, wo ich das genau gesagt habe. Wo ich gesagt haben soll, dass ein O(n^2)-Algo besser sei als ein O(n)-Algo habe ich nämlich nicht finden können. Ich habe lediglich nahegelegt, dass man sich auch die Konstanten bei Gelegenheit mal anschaun sollte. Lies die Beiträge vielleicht einfach nochmal unter diesem Gesichtspunkt. Und wenn Du Zeit hast, google mal nach "Algorithm Engineering"... eine relativ neue Forschungsrichtung (oder sind die alle fehlgeleitet? ;))

Xin

DEvent schrieb:

Er ist Student, er darf noch Fehler machen. Der Umkehrschluss bedeutet ja nicht, dass Studenten alles falsch machen.
In die Frage der Komplexität habe ich mich nirgendwo eingemischt, weil sie nichts mit dem Thema zu tun hat. n ist konstant, da es sich um den identischen Algorithmus handelt, und k nervt den Anwender, mehr gibt's dazu nicht zu sagen.

Yo lassen wir das, ich geb mich geschlagen.

f(x) = ax+b.
Unabhängig davon, ob man a=k setzt oder b=k, die Funktion bleibt linear von x abhängig ist. Darum geht's bei der O-Notation. Kommen mehr Daten hinzu, ändert sich das Laufzeitverhalten nicht n^2 oder n log n oder sonst was.
O( n ) = O( a*n ) = O( n+b ) = O( a*n+b ).
Pro Datensatz steigt die Laufzeit linear. Fertig.

Davon unabhängig bedeutet k aber, dass der Anwender k * länger pro Datensatz warten muss. Den wird das schon nerven und er wird sich für das Produkt entscheiden, dass die Antwort schneller findet.

Danke, ich kann wohl doch besser JavaScript als du

Ich schreibe Compiler, keine Websites. Ich hoffe für Dich, dass Du JS besser kannst als ich.

Shade Of Mine schrieb:

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?

Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.

Begründe das.

Shade Of Mine schrieb:

Beantworte mir also bitte die Frage:
warum ist Lisp kein OO? Warum sind Klassen und Vererbung besser als Prototypes und Objekt klonen? Warum sind virtuelle Funktionen besser als Multimethods?

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

Shade Of Mine schrieb:

Solange du das nicht beantworten kannst - ist deine OO Argumentation Fehlerhaft, weil sie viele Aspekte einfach ignoriert.

Fragen beantwortet, obwohl sie teils "Warum ist es nachts kälter als draußen?" Charakter haben. Hast Du noch mehr Fragen?

Shade Of Mine schrieb:

Der Ausdruck mit Nachrichten ist nichts anderes als eine Formulierung um zu betonen dass es um die Objekte geht die das Verhalten bestimmen.

...der nächste, der abschreibt, was ich sage und es als Argument verwenden möchte... Du bist #4 in diesem Thread, denkt euch doch mal was neues aus.

Shade Of Mine schrieb:

Aber der Punkt ist ja: wir behaupten man kann sie nicht genau definieren weil sie eine denkweise ist und klammerst dich an C++ und Java um OOP zu definieren. Dabei ignorierst du, dass es komplett andere Sprachen gibt die ebenfalls OOP Konzepte anbieten.

Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.
Sprachen neben C++ oder Java machen mir keine bisher Probleme. Mal eben "LISP" einzuwerfen ohne etwas konkretes zu aufzeigen, was meiner Aussage widerspricht, ist dafür etwas wenig.
Zumal Du erstmal Deine Definition an C++ belegen darfst - ich erinnere an die immernoch nicht beantwortete Frage von mir.
Wenn meine Definition auf LISP nicht passen würde, dann wäre das schlecht, aber die "Standard"-Definition passt nichtmals auf C++.

Shade Of Mine schrieb:

In C++ und Java sieht man eben nur einen kleinen Teil der OOP. Wobei du halt auch dort Teile der OOP die sich nicht miteinander schneiden ignorierst. zB statische Polymorphie - aber wo trennt man da?

Überladene Funktionen sind Funktionen gleichen Namens aber unterschiedlicher Signatur. Sie sind damit vom Compiler problemlos zu unterscheiden. Statische Funktionen sind grundsätzlich nicht objektorientiert, sie sind eben statisch. Und sie bleiben statisch, wenn sie in einem anderen Namespace liegen. Ich sehe da eine ganz klare Grenze, die absolut keine Frage läßt: nicht OOP.

Shade Of Mine schrieb:

Ist statische Polymorphie keine echte Polymorphie weil zur Laufzeit nichts geänedert werden kann? Aber Java geht noch weiter: man kann die Klassen zur Laufzeit erst _erstellen_. Etwas das in C++ nicht geht. Ist jetzt die dynamische Polymorphie in C++ weniger Polymorph als in Java? Denn Java bietet eine deutlich bessere Laufzeit Polymorphie was die dynamik betrifft. Wo genau trennt man da?

Der Spaß heißt Reflection. Falsche Baustelle.
Templates können auch objektorientierte Klassen erstellen - müssen es aber nicht. Weder brauchst Du Templates oder Reflection für OOP, noch OOP für Templates oder Reflection. Du darfst sie aber gerne zusammen verwenden.

scrub

Xin schrieb:

Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.

Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

Xin

scrub schrieb:

Xin schrieb:

Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.

Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.

Ich gehe mal davon aus, dass Du absichtlich im Dreiersystem rechnest und nicht im Zweiersystem, um 4 auszudrücken.

Wenn nicht, solltest Du überlegen, ob Du Dich mit Deiner Meinung nicht zu schnell festgelegt hast.

scrub schrieb:

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.

Wenn Du OOP so definierst, brauchst Du keine Definition, Du kannst auch einfach Programmiersprache sagen, das wäre gleichwertig.

Helium

Xin schrieb:

Shade Of Mine schrieb:

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?

Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.

Begründe das.

Vorher die Frage, ob du jemals mit Smalltalk gearbeitet hast.

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.

Multimethoden werden dynamisch dispatched, im gegensatz zu deinem operator+ in C++.

Wenn du keine Probleme mit pototyp-basierter OO hast, was hast du dann gegen JavaScript?

Warum gerade LISP? Er hätte auch Dylan nehmen können. Es geht eben darum, das jede beliebige Funktion dynamisch dispatchen kann.

Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

MAchen wir mal konkrete Beispiele: Es gibt Sprachen, in denen die Punkt-Notation zum Methodenaufruf nur Syntax-Zucker ist.

object.methode(argument)

und

methode(object, argument)

sind dort beides gültige Schreibweisen und beide haben natürlich das selbe Laufzeitverhalten. Es ist ja auch nur ne andere Syntax, sonst nix. Man kann aber auch sagen, dass außedem auch anhand des Typs des "zweiten" Arguments (hier 'argument') dynamisch zu dispatchen. Und schon hat man eine Multimethode.

Ich kann die Methoden innerhalb der Klasse definieren oder außerhalb. Beide erlauben die selbe Aufrufsyntax, beide dispatchen gleichermaßen dynamisch. Lediglich die zugriffsrechte auf Private Teile der Klasse sind unterschiedlich.

Das nur vielleicht als Horizont-Erweiterung.

Templates können auch objektorientierte Klassen erstellen

Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.

Helium

Xin schrieb:

Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.

In wie weit unterstützt mich Assembler denn dabei diese Art zu denken auch einzusetzten?
Ermöglichen != Unterstützen.

Mr. N

asc schrieb:

Jester schrieb:

edit: C++ hatte zusätzlich noch das Problem, dass immer sowas wie x = x + ... dastand. Daraus ein += zu machen brachte auch einiges. Das dürfte durchaus in ne ähnliche Kategorie fallen wie der StringBuffer-Fehler.

Mal davon Abgesehen das auch in C++ das "StringBuffer"-Problem bestand. Den bei vielen Stringadditionen nutzt man auch unter C++ eher ein entsprechendes Streamobjekt.

Das sind komplett unterschiedliche Problematiken. std::string ist eher vergleichbar mit StringBuffer nur dass es keine "string+int"-Overloads gibt, daher wird zum Bauen von Strings mit Zahlen etc. ein anderes Mittel nötig. stringstreams eben.

asc schrieb:

Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.

Der Rees-OO-Artikel? Äh ja, das kannst du natürlich wunderbar bewerten.

rüdiger

Xin schrieb:

Yepp. Mit Deiner Definition ist Assembler eine Sprache, die OOP unterstützt, weil dort ebenso Objekte verwendet werden.

Wenn Du OOP so definierst, brauchst Du keine Definition, Du kannst auch einfach Programmiersprache sagen, das wäre gleichwertig.

Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen. Aber das gilt doch für alle Paradigmen.

( "Ein Geisterfahrer?! TAUSENDE!" )

Mr. N schrieb:

asc schrieb:

Sagen wir einfach: Wer auch immer den Artikel verfasst hat, hat keine Ahnung von der Materie gehabt, oder "seine" Sprache einfach gut darsellen wollen.

Der Rees-OO-Artikel? Äh ja, das kannst du natürlich wunderbar bewerten.

Er spricht von dem Performance-Artikel (so habe ich es zumindest verstanden).

Xin

Helium schrieb:

Xin schrieb:

Shade Of Mine schrieb:

In den letzten Postings klammert man sich an Nachrichten. Bemerkt denn niemand, dass "Nachrichten" ein theoretischer Ansatz zur OOP ist und überhaupt nichts mit der Realität zu tun hat, die in C++, C#, Java stattfindet?

Und genau das ist dein Fehler. C++, C# und Java bieten dir nur einen eingeschränkten Blickwinkel auf OOP.

Begründe das.

Vorher die Frage, ob du jemals mit Smalltalk gearbeitet hast.

Nein.

Helium schrieb:

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.

Multimethoden werden dynamisch dispatched, im gegensatz zu deinem operator+ in C++.

Beschreibe den Ablauf von 'dynamisch dispatched' mal ganz detailiert.

Helium schrieb:

Wenn du keine Probleme mit pototyp-basierter OO hast, was hast du dann gegen JavaScript?

Wo steht, dass ich was gegen JavaScript habe? Und selbst wenn, was hat es mit OOP zu tun?

Helium schrieb:

Templates können auch objektorientierte Klassen erstellen

Klassen können also Objektorientiert sein.
Definiere dann möglichst genau, wann eine Klasse objektorientiert ist.

Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.

Ansonsten möchte ich das gerne umformulieren, bevor jemand einwendet, dass Klassen nicht objektorientiert sein können, da sie nur eine Beschreibung darstellen: Templates können auch Klassen erstellen, die Objekte erstellen, die sich zur objektorientierten Programmierung eignen.

Müssen sie aber nicht.

Xin schrieb:

Sobald virtual enthalten ist und virtuelle Methoden in abgeleiteten Klassen überschrieben werden.

Ich wette, dass sich die Entwickler von z.B. Sun krummlachen, wenn ich an die herantrete und behaupte, dass ihre String-Klasse nicht objektorientiert sei, da man keine Methoden überschreiben kann. Eine komische Definition von OOP, die du da hast. Es ist ja aber weitläufig bekannt, dass Java eine Multi-Paradigma-Sprache ist, immerhin unterstützt sie objektorientierte und klassenorientierte (!) Programmierung.

minhen

Xin argumentiert zwar als einziger hier überzeugend - aber vielleicht sollte man sich dennoch auch mal ansehen, wie Bjarne Stroustrup Objekt-Orientierung definiert. Schließlich beruft sich Xin auch auf ihn.

Stroustrup definiert OOP nach obigem Link als:
1. Kapselung/Abstraktion
2. Vererbung
3. Laufzeit-Polymorphie

Damit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht. Denn ohne Laufzeit-Polymorphie ist das Kriterium der Objekt-Orientierung eben nicht vollständig erfüllt.

Sehr schön ist übrigens auch das Beispiel, welches Stroustrup dort anführt

rüdiger schrieb:

Code ist OOP und nicht eine Programmiersprache. Die Programmiersprache kann beim OOP höchstens helfen.

Davon abgesehen, dass du eine Erklärung für deine Aussage schuldig bleibst, erzwingt sie geradezu ein Zitat aus dem Paper, welches Stroustrup bei der OOP-Definition verlinkt:

A language or technique is object-oriented if and only if it directly supports:
[1] Abstraction – providing some form of classes and objects.
[2] Inheritance – providing the ability to build new abstractions out of existing ones.
[3] Run-time polymorphism – providing some form of run-time binding.

Mr. N

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend

Schön, dass du den ganzen Thread gelesen hast.

Phoemuex

scrub schrieb:

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

Ich habe diesen Thread jetzt 17 Seiten lang gelesen und langsam wird es mir zu blöd.

Man muss doch drei Dinge einsehen können.

Die Definition, die du für OOP benutzt, ist nicht die gängige. Du nimmst einen Teil dessen, was allgemein als OOP verstanden wird (virtuelle Methoden, bzw. Polymorphie, virtuelle Methoden sind ja praktisch nur ein Implementierungsdeteil, um Polymorphie zu erreichen) und definierst das als das einzig und allein von OOP bezeichnete. Das ist aber im üblichen Sprachgebrauch nicht so. Dort ist es nämlich so, dass der Begriff OOP sehr viele verschiedene Dinge wie Kapselung, Polymorphie, Typsicherheit und vor allem die Zusammenlegung von Daten und Funktionen zu einem Datentyp bezeichnet. D.h. es existieren nicht getrennt Daten und Funktionen, sondern man schreibt eine Klasse, die sowohl die Daten als auch die Methoden, d.h. die Funktionalität der Objekte der Klasse bestimmt.
Du reitest darauf herum, dass es OBJEKT-orientier heißt, und hälst anderen vor, dass bei allen Bestandteilen der OOP (nach meinem Verständnis) kein OBJEKT benutzt/gebraucht wird, weil der dynamische Typ nicht gebraucht wird. Was man aber sehen muss, ist das jedes Objekt auch einen STATISCHEN TYP hat. Und auf den kann man sich doch mit dem gleichen Recht wie auf den dynamischen beziehen und das ganze dann Objektorientiert nennen.
Warum dir keiner WIRKLICH widerspricht: Es ist halt (wie oben gesagt) so, dass OOP sehr unscharf definiert ist und deswegen kann man kein Zitat finden, dass dir explizit widerspricht (auch wenn ein paar Quellen ja in die Richtung gehen). Aber deine bisher gebrachten Zitate/Quellen untersützten deine Meinung auch nicht wirklich.

Um nur mal ein Beispiel zu bringen, ein Zitat aus Marc++us Buch, welche Konzepote alle unter OOP verstanden werden:

Objekte, Klassen, Vererbung, Polymorphie, Späte Bindung, Kapselung.

Das 2. Kapitel in genau dem Buch heißt übrigens "Wieso eigentlich nicht 'klassenorientierte Programmierung'". Eine wirkliche Antwort darauf wird allerdings auch nicht gegeben Es liegt halt daran, dass man das Verhalten von Objekten in der OOA analysiert, um daraus Klassen zu abstrahieren und nachher wieder mit OBJEKTEN dieser Klasse arbeitet. Ohne irgendwelche Instanzen nutzen die schönsten Klassen nichts (oder sind nicht mehr als namespaces)...

Wenn das jetzt auch nicht reicht, Pech gehabt... Irgendwann muss das hier doch mal ein Ende haben. Sonst wälze ich gleich auch noch den Struppi und suche ein vernünftiges Zitat, das die gängige Fassung belegt.

Mehr als diese Erklärung und die gängige Meinung + Belege dafür kann man wirklich nicht verlangen, um von der Haarspalterei um die OBJEKT anstatt Klassen orientierte Programmierung wegzukommen...

Um nochmal darauf hinzuweisen: Es geht hier eigentlich um "Performancemythen". Dazu steht auch etwas schönes in Marc++us Buch:

Haben Sie auch schon davon gehört, dass C++ langsam ist, weil man nie direkt auf die Variablen zugreift? Unsinn, lassen Sie sich davonkeine Angst machen. Der Zugriff mit einer kleinen kurzen get-Methode auf eine Variable wird von einem optimierenden Cimpiler so gut übersetzt, dass es nur einige Taktzyklen länger dauert, als direkt auf die Variable zuzugreifen. Es gibt keinen Grund, wegen der Rechenzeig hier einen Kompromiss einzugehen, dies ist am falschen Ende gespart.

Dazu kommt natürlich auch noch inline + Optimierungen, sodass im besten Fall sogar gar keine Methode aufgerufen wird...

Endlich mal wieder Ontopic (obwohl die Ausschweifung mit der Komplexität und der O-Notation ja auch relativ on-topic war).

Vielleicht sollte mal wer ein Gesetz aufstellen, dass das auftreten eines Flamewars in Abhängigkeit der Benutzer eines Forums beschreibt. So was ähnliches wie Godwins Gesetz.

Felix

finix

minhen schrieb:

Damit entspricht Xins "provokante" Aussage, C++-Code wäre ohne virtual nicht objekt-orientiert, voll und ganz dem, was Stroustrup sagt und unter OOP versteht.

Jester

minhen schrieb:

Xin argumentiert zwar als einziger hier überzeugend

Mich wundert ehrlich gesagt was Du als überzeugend ansiehst. Er behauptet irgendwelche Dinge, geht auf keine Argumente ein. Standard-Definitionen bzw. Referenzen auf diese werden damit abgebügelt, dass man ja offensichtlich nicht in der Lage sei sich kritisch mit den Sachen auseinanderzusetzen. Das überzeugt mich zwar auch, aber von anderen Dingen als vom Autor vorgesehen.