Performancemythen?

Undertaker

evilissimo schrieb:

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

bingo!
~40 seiten nur deshalb, weil alle aneinander vorbei reden.

Xin

Jester schrieb:

Xin, Du magst wissen was ich mit dazuerfinden und ignorieren meine? Bitteschön:
Ich habe erklärt, was ich mit Zusammenfassung von Funktionen und Daten zu Objekten meine (weiter oben habe ich erklärt, wie ich daraus OOP ableite). Daraufhin hast Du dazuerfunden, dass es was mit dem ersten Parameter einer Funktion zu tun hätte. Dann habe ich erklärt was das unterscheidet. Das hast Du ignoriert und mich erneut darauf hingewiesen, dass es ja nur auf den ersten Parameter ankommt.

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.
2. Mir ist keine sinnvolle Erklärung eines Unterschiedes aufgefallen.

evilissimo schrieb:

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

Ich bin praktisch veranlagt. Seit der technischen Umsetzung von Goto haben sich Computer im Konzept und damit in ihren Möglichkeiten nicht weiterentwickelt.

Solange sich da nichts ändert, gibt die Maschine die Möglichkeiten vor. Der Compiler übersetzt unsere Sourcecodes auf die Maschine. Ich orientiere mich an der Maschine. Programme werden objektorientiert gesteuert oder statisch.
"Plain classes" laufen statisch ab, C++-Klassen mit virtual laufen objektorientiert ab - auch auf Ebene der Maschinensprache. Das Schlüsselwort virtual schaltet die OOP-Funktionalität hinzu, das fehlen von virtual in C++ bedeutet, dass man OOP entweder selbst implementieren muss oder darauf verzichtet.

Wer "plain classes" oder "templates für plain classes" bereits als OOP bezeichnen möchte, arbeitet mit einem theoretischen Konstrukt, dass in keinem Zusammenhang mit dem steht, was auf der Maschine bearbeitet wird. Von "eurem OOP" bleibt nach der Übersetzung nichts über, was sich von einem C Programm oder Assemblerprogramm unterscheidet. "plain classes" genießen die Unterstützung von C und auch von Assembler. Meine Form von OOP ist in C oder Asm nicht unterstützt, muss man halt selbst implementiert werden.

Die Maschine ist die Realität mit der ein Entwickler klarkommen muss.
Entsprechend kann man seine Sichtweise an der Realität ausrichten oder sich etwas anderes ausdenken. Das, was man sich anderes ausdenkt, muss aber schlussendlich auf die Maschine übertragen werden und "plain classes" schaffen es nicht bis auf die Maschine.
Die vielen Definitionen, die hier beschrieben wurden und inzwischen schon als "unsere Definition" bezeichnet wird, hat mal Auswirkung auf die Maschine (wenn in C++ virtual verwendet wird), mal nicht.
Viel Spaß mit einem theoretischen Konstrukt.

Ich beende den Thread hiermit.

Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Möge er in Frieden ruhen.

Apollon

Xin schrieb:

Ich beende den Thread hiermit. [...] da es in dem Thread vorrangig darum geht gegen mich zu sein...

Glaub mir, so wichtig bist Du nun auch nicht.

otze

ging der thread nicht über Performancemythen?

hustbaer

Bisher ist es argumentativ nie eng geworden, aber es wird wirklich alles gegen "meine" Definition angekarrt, nur um dagegen zu sein.

Es ist nie eng geworden weil du einfach nicht darauf eingehst was andere schreiben. Ist sehr einfach so seinen Standpunkt zu vertreten.

rüdiger

Xin schrieb:

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.

Nö, wie ich schon sagte: Schau dir bitte mal mehr Programmiersprachen an. Deine Einfältigkeit stimmt einen traurig und raubt dir aus meiner Sicht jede Kompetenz eine vernünftige Definition der OO zu treffen.

Xin schrieb:

Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Möge er in Frieden ruhen.

Du bist wirklich Arrogant und eingebildet Wenn du Gegenargument als persönlichen Angriff empfindest ist das einfach nur lächerlich!

Xin schrieb:

Ich bin praktisch veranlagt. Seit der technischen Umsetzung von Goto haben sich Computer im Konzept und damit in ihren Möglichkeiten nicht weiterentwickelt.

Ne, Du bist praktisch gefangen. Du klebst geradezu an bestimmten konkreten Dingen und kannst keinen Millimeter abstrahieren- daher ist es ja auch nicht verwunderlich, daß Du theoretische Informatiker als "nur theoretisch Informatiker" verhöhnst.

Xin schrieb:

Ich beende den Thread hiermit.
Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Du bist so unglaublich arrogant. Nur nochmal zur Erinnerung: Du stehst hier nicht vor einem Tutorium, Du bist nicht derjenige, der "hier den Erklärbär spielen" muß. Du schätzt Deine Position völlig falsch ein und benimmst Dich ständig daneben, indem Du anderen Leuten Dummheit, Ignoranz und mehr unterstellt- das führt auch dazu, daß Dich vermutlich niemand leiden kann. Es fällt nicht vom Himmel und liegt auch nicht an Deiner Genialität, sondern Du hast angefangen, andere runterzumachen, und deswegen bist Du unbeliebt. Das ist natürlich keine gute Ausgangslage, wenn man andere überzeugen will. Das hast Du Dir ganz allein zuzuschreiben.

Ich bin übrigens kein Diplominformatiker, werde nie einer sein und finde Deine Definition trotzdem merkwürdig, falls Dich das beruhigt. Falls ich jetzt wieder mal nur von Dir abgeschrieben haben sollte, tut es mir sehr leid.

Theston

Beeindruckend, wie eine einzelne Person 40 Seiten lang so konsequent trollen kann.

Shade Of Mine

Xin schrieb:

Programme werden objektorientiert gesteuert oder statisch.
"Plain classes" laufen statisch ab, C++-Klassen mit virtual laufen objektorientiert ab - auch auf Ebene der Maschinensprache.

Sehe ich überhaupt nicht. In Assembler Code steht uU so etwas:

void draw(Class* p) {
  switch(p->type) {
  case TRIANGLE_CLASS:
    return triangle_draw(p);
  case CIRCLE_CLASS:
    return circle_draw(p);
  }
  return pure_virtual_function_called_error();
}

Wenn man nun daran OO Code definieren will...

Aber OK, wenigstens habe ich jetzt eine Ahnung was für dich OOP. Wo sich diese "Definition" komplett beißt ist Pseudo Code. Man kann keinen OO-Code skiziieren weil es keinen Compiler gibt der ihn versteht. Naja - ok.

Zu Behaupten seit goto hat sich nichts geändert ist übrigens eine Widerlegung deiner OOP Definition -> da alles eh nur gotos sind, ist jeder Code nur doofer Spaghetti Code.

Lies dir den Thread am besten in 5 Jahren nochmal durch - vielleicht bist du dann weit genug OOP auf einer abstrakteren Ebene zu verstehen.

Brutus

Viel beeindruckender ist doch eher, dass er den ganzen Quatsch, den er hier andauernd versucht herunterzubeten, sogar ernst meint. Er ist fest davon ueberzeugt. Mit Trollen hat das schon lange nichts mehr zutun, dennoch vermag mir gerade ein praeziser Begriff dafuer nicht einfallen.

Undertaker

Shade Of Mine schrieb:

Zu Behaupten seit goto hat sich nichts geändert ist übrigens eine Widerlegung deiner OOP Definition -> da alles eh nur gotos sind, ist jeder Code nur doofer Spaghetti Code.

das kannste so nicht sagen. nach Xin's definition wäre ein assembler-code mit indirekten sprüngen 'JMP [R0]', d.h. die nächste position des instruction pointers wird zur laufzeit berechnet, durchaus objektorientiert.

this-*gt*that

Gabs die letzten 40 Seiten irgend ne brauchbare Erkenntnis?

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?
- Ist ein Objekt was nur einmal im Programm vorkommt nichtmehr OO?

Undertaker

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

evilissimo

Tellerrand schrieb:

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?
- Ist ein Objekt was nur einmal im Programm vorkommt nichtmehr OO?

Ich sag nur Singleton

evilissimo

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

LISP ist da dann das gegenbeispiel

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

Wozu gibt es dann die Klasse Class?
Na ganz so einfach würde ich es mir nciht machen

Shade Of Mine

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

Eine Klasse kann ein Objekt sein - sie muss aber nicht.

Undertaker schrieb:

in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html :p

Undertaker

Shade Of Mine schrieb:

Eine Klasse kann ein Objekt sein - sie muss aber nicht.

doch ist ein Object schrieb:

Undertaker schrieb:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Class.html :p

tja, da seht ihr's....