Performancemythen?

[Shade Of Mine]

Xin schrieb:

OOP kommt dann rein, wenn Lampe zum Beispiel nicht mit Dynamo kombiniert wird, sondern von Energiequelle.
Energiequelle könnte Dynamo sein oder Akku.
Energiequelle::GetVoltage() wäre eine virtuelle Funktion, die beim Dynamo von der Drehzahl abhängt und beim Akku von der Ladung der Zellen.

Ersetzen wir Energiequelle durch ein Abstraktes Konzept dass nicht direkt im Sourcecode vorkommt und implementieren Dynamo und Akku. Und geben Lampe dann ein Objekt von Dynamo oder Akku je nachdem wie wir lustig sind.

Genau das machen _alle_ meine Shape Codes. Die Implementierung von Energiequelle unterscheidet sich - da unterschiedliche Sprachen mir unterschiedliche Tools anbieten diese Implementierung vorzunehmen - aber das Konzept von Akku und Dynamo die miteinander austauschbar sind ist das essentielle in den Codes.

Die Implementierung sollte Nebensache sein.

[Xin]

dv_ ignoriere ich mal.

merker schrieb:

dv_ schrieb:

"Sourcecode OOP, Executable kein OOP."

Wie kommst Du jetzt darauf ? Wo steht denn das ?

Wie komme ich darauf?
Der Programmierer verlangt OOP, also ist der Sourcecode so geschrieben, dass mit OOP arbeiten soll.

Wenn es allerdings keine abgeleiteten Objekte gibt, ist OOP nicht notwendig, es verlangsamt den Funktionsaufruf.
Erkennt der Compiler das, ist es sinnvoll OOP aus dem Programm zu entfernen, um das Executable zu beschleunigen.
Der Code, den der Compiler dann als Executable schreibt, arbeitet dann nur noch mit statischen Funktionsaufrufen, also nicht mehr objektorientiert.

Wo steht das?
Es ist die logische Konsequenz, wenn der Compiler OOP rausoptimiert, dass der OOP-Quelle zu einem Nicht-OOP-Ziel kompiliert wird.

[otze]

merker schrieb:

dv_ schrieb:

"Sourcecode OOP, Executable kein OOP."

Wie kommst Du jetzt darauf ? Wo steht denn das ?

Xin schrieb:

Was ist, wenn der Compiler erkennt, dass es kein Tier gibt, dass die methode überschreibt und deshalb den vcall herausoptimiert? immernoch oop?

OOP vom Entwickler gewünscht, vom kleveren Compiler rausoptimiert.
Sourcecode OOP, Executable kein OOP.

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

OOP kommt dann rein, wenn Lampe zum Beispiel nicht mit Dynamo kombiniert wird, sondern von Energiequelle.
Energiequelle könnte Dynamo sein oder Akku.
Energiequelle::GetVoltage() wäre eine virtuelle Funktion, die beim Dynamo von der Drehzahl abhängt und beim Akku von der Ladung der Zellen.

Ersetzen wir Energiequelle durch ein Abstraktes Konzept dass nicht direkt im Sourcecode vorkommt und implementieren Dynamo und Akku. Und geben Lampe dann ein Objekt von Dynamo oder Akku je nachdem wie wir lustig sind.

Was ist ein "abstraktes Konzept, das nicht direkt im Sourcecode vorkommt"?

[dv_]

Xin schrieb:

dv_ ignoriere ich mal.

merker schrieb:

dv_ schrieb:

"Sourcecode OOP, Executable kein OOP."

Wie kommst Du jetzt darauf ? Wo steht denn das ?

Wie komme ich darauf?
Der Programmierer verlangt OOP, also ist der Sourcecode so geschrieben, dass mit OOP arbeiten soll.

Wenn es allerdings keine abgeleiteten Objekte gibt, ist OOP nicht notwendig, es verlangsamt den Funktionsaufruf.
Erkennt der Compiler das, ist es sinnvoll OOP aus dem Programm zu entfernen, um das Executable zu beschleunigen.
Der Code, den der Compiler dann als Executable schreibt, arbeitet dann nur noch mit statischen Funktionsaufrufen, also nicht mehr objektorientiert.

Wo steht das?
Es ist die logische Konsequenz, wenn der Compiler OOP rausoptimiert, dass der OOP-Quelle zu einem Nicht-OOP-Ziel kompiliert wird.

Du glaubst allen ernstens, dass OOP nur aus dynamic dispatch besteht? Mann, du hast wirklich eiskalt alle Messlatten vergraben. Lass dir gesagt sein: OOP ist mehr als nur dynamic dispatch.

Aber ignorier mich ruhig weiter. Irgendwann wirst du einsehen was für Unsinn du redest. Hoffentlich bevor es dich deinen Job kostet.

[minhen]

rüdiger schrieb:

Hier mal ein Beispiel mit Common Lisp (CLOS)

Ich erweitere das Sammelsurium einfach mal aus Spaß an der Freude mit Perl:

use fields;

package Tier;
sub new { return fields::new(shift); }
sub laut { print "dunno\n"; }

package Hund;
use base 'Tier';
sub laut { print "wuff wuff\n"; }

package Katze;
sub new { return fields::new(shift); }
sub laut { print "miau miau\n"; }

package main;
eval("eval 'new '.<> or new Tier")->laut;

~$ perl bsp.pl
Hund
wuff wuff
~$ perl bsp.pl
STH
dunno
~$ perl bsp.pl
Katze
miau miau

[Xin]

dv_ schrieb:

Du glaubst allen ernstens, dass OOP nur aus dynamic dispatch besteht? Mann, du hast wirklich eiskalt alle Messlatten vergraben. Lass dir gesagt sein: OOP ist mehr als nur dynamic dispatch.

Ist das alles, was als Begründung kommt?
Wenn Du mir etwas mitteilen möchte, dann stelle nicht nur Behauptungen auf, sondern begründe sie.

[otze]

Was ist das denn für eine Frage? Du zeigst mir nichts und ich soll sagen, was das ist?
Hab ich 'ne Kristallkugel? Ich weiß ja nicht, was der Code da macht.
Nur weil da Miau rauskommt, weiß ich doch nicht, ob der Entwickler per OOP gelöst hat oder nicht.

das bedeuted, dass deine definition in 90% aller großprojekte nichtmehr sinnvoll zum einsatz kommen kann. tolle definition, ehrlich. so mathematisch korrekt...und nützlich.

[Xin]

otze schrieb:

Was ist das denn für eine Frage? Du zeigst mir nichts und ich soll sagen, was das ist?
Hab ich 'ne Kristallkugel? Ich weiß ja nicht, was der Code da macht.
Nur weil da Miau rauskommt, weiß ich doch nicht, ob der Entwickler per OOP gelöst hat oder nicht.

das bedeuted, dass deine definition in 90% aller großprojekte nichtmehr sinnvoll zum einsatz kommen kann. tolle definition, ehrlich. so mathematisch korrekt...und nützlich.

Keine Definition kommt sinnvoll zum Einsatz, wenn Du nicht die Informationen hast um eine Antwort zu geben.

Wer ein Auto mietet und an die Tankstelle fährst, stellt oft fest, dass das Auto fährt, obwohl man nicht weiß, ob man Benzin oder Diesel tanken muss.
Trotzdem ist entweder ein Benzinmotor drin - oder ein Diesel.

Wenn man die Motorhaube öffnet oder sich in der Dokumentation informiert, dann kann man das entscheiden.

Man kann natürlich auch sagen, dass die Definition Benzin oder Diesel nichts taugt und einfach Kraftstoff verlangen.

[dv_]

Xin schrieb:

Ist das alles, was als Begründung kommt?
Wenn Du mir etwas mitteilen möchte, dann stelle nicht nur Behauptungen auf, sondern begründe sie.

Die Grundlage von OO ist die sinnvolle Zusammenführung von Daten und Funktionalität zu Objekten. Punkt aus ende. Aber du kommst mir Spezialisierungen daher und nennst das OOP. Das ist so, als ob man sagt, dass ein Ding nur dann ein Vehikel ist, wenn es ein Lenkrad hat und Porsche heisst.

[Xin]

dv_ schrieb:

Xin schrieb:

Ist das alles, was als Begründung kommt?
Wenn Du mir etwas mitteilen möchte, dann stelle nicht nur Behauptungen auf, sondern begründe sie.

Die Grundlage von OO ist die sinnvolle Zusammenführung von Daten und Funktionalität zu Objekten. Punkt aus ende. Aber du kommst mir Spezialisierungen daher und nennst das OOP. Das ist so, als ob man sagt, dass ein Ding nur dann ein Vehikel ist, wenn es ein Lenkrad hat und Porsche heisst.

Falsch, ich verlange Räder.

Räder funktionieren mit einem Fahrer (int), mit Beifahrer ( Array ) und auch als Transporter (Klasse).
Der Fahrer (int) kann aber auch zu Fuß gehen, genauso wie die Beifahrer und auch eine Palette kann man notfalls tragen.

Ansonsten sind Diskussion mit Personen, die "Punkt aus ende" formulieren kaum nutzbringend.

[dv_]

Du weisst aber schon, dass Vehikel nicht unbedingt Räder brauchen, oder? Wozu braucht ein Schiff räder? Ja, ein Schiff ist ein Vehikel.

Davon abgesehen ist dein Beispiel überhaupt total verkorkst. Du bist extrem C++-versteift. Lerne doch endlich, dass es andere Modelle gibt. Verschiedene Beispiele anderer Sprachen wurden dir gezeigt.

[Gast]

Xin schrieb:

Wo steht das?
Es ist die logische Konsequenz, wenn der Compiler OOP rausoptimiert, dass der OOP-Quelle zu einem Nicht-OOP-Ziel kompiliert wird.

Besten Dank für die Antwort.
Könnte Alpträume verursachen, wenn die Executable nicht mehr dem Sourcecode entspricht.
Ist aber wohl ein anderes Thema.

[Gast]

Was haben wir hier eigentlich. Wir haben zwei Parteien: Die eine hat eine schwammige, unpräzise Definition von OOP, die andere eine harte, präzise. Was mich dabei aber wundert ist, dass in einem Forum mit den übelsten Pedanten, ANSI-Standard-Fetischisten und undefined-behaviour-Propheten eben die unexakte, schwammige Definition besser angenommen wird. Müssten diese nicht alle (den Matheloser Jester mal ausgenommen) den Weg der peinlichst genauen Definition gehen? Woher kommt das? Liegt es vielleicht letzten Endes doch daran, dass die präzise Definition einfach nur unbrauchbar ist, weil sie einfach zu speziell ist?
Mir kommt es so vor, als definiert jemand "Speiseeis" als "Mischung aus Wasser und Milch in festem Aggregatszustand mit Zucker und Zartbitterschokoladepartikeln mit definierter Größe", während der Pöbel das einfach nur als "na Eis halt" definiert. Bei der ersten Definition ist eindeutig, dass Stracciatella gemeint ist. Der Pöbel hingegen kann sich theoretisch die Zunge am Trockeneis einfrieren, aber sollte da nicht schon längst der "common sense" eingesetzt haben?

[Shade Of Mine]

Xin schrieb:

Was ist ein "abstraktes Konzept, das nicht direkt im Sourcecode vorkommt"?

Shape in dem C++ Template Beispiel

[Aprollo]

Oder auch Policy-Based Design genannt

[rüdiger]

minhen schrieb:

rüdiger schrieb:

Hier mal ein Beispiel mit Common Lisp (CLOS)

Ich erweitere das Sammelsurium einfach mal aus Spaß an der Freude mit Perl:

iiiih ist ja grauenhaft :p Aber dennoch schön OOP (auch wenn einige es hier nicht glauben mögen...)

[finix]

Tim schrieb:

Was haben wir hier eigentlich. Wir haben zwei Parteien: Die eine hat eine schwammige, unpräzise Definition von OOP, die andere eine harte, präzise. Was mich dabei aber wundert ist, dass in einem Forum mit den übelsten Pedanten, ANSI-Standard-Fetischisten und undefined-behaviour-Propheten eben die unexakte, schwammige Definition besser angenommen wird. Müssten diese nicht alle (den Matheloser Jester mal ausgenommen) den Weg der peinlichst genauen Definition gehen? Woher kommt das? Liegt es vielleicht letzten Endes doch daran, dass die präzise Definition einfach nur unbrauchbar ist, weil sie einfach zu speziell ist?
Mir kommt es so vor, als definiert jemand "Speiseeis" als "Mischung aus Wasser und Milch in festem Aggregatszustand mit Zucker und Zartbitterschokoladepartikeln mit definierter Größe", während der Pöbel das einfach nur als "na Eis halt" definiert. Bei der ersten Definition ist eindeutig, dass Stracciatella gemeint ist. Der Pöbel hingegen kann sich theoretisch die Zunge am Trockeneis einfrieren, aber sollte da nicht schon längst der "common sense" eingesetzt haben?

Das Problem ist ganz einfach dass es eine solche Definition ganz einfach nicht gibt.

Xin bastelt sich da aus seinen C++-Kenntnissen selber eine Definition (die im Endeffekt wohl genauso schwammig, unpräzise und sicher inkonsistent ist) zurecht, die hinten und vorne nicht so allgemeingültig und vor allem allumfassend ist wie er sich einbildet.

[rüdiger]

Xin schrieb:

dv_ schrieb:

Du glaubst allen ernstens, dass OOP nur aus dynamic dispatch besteht? Mann, du hast wirklich eiskalt alle Messlatten vergraben. Lass dir gesagt sein: OOP ist mehr als nur dynamic dispatch.

Ist das alles, was als Begründung kommt?
Wenn Du mir etwas mitteilen möchte, dann stelle nicht nur Behauptungen auf, sondern begründe sie.

a.foo();

Nachricht an ein Objekt gesendet => OOP.

class A {
public:
  void foo();
};

A a;

wow gilt immer noch!

class A {
public:
  virtual void foo();
};

A a;

und immer noch!

Ist nämlich unabhängig von den Interna der Klasse.

a.bar = 10;

wow, Nachricht an eine Objekt gesender => OOP. Total toll

a();

und hier das gleiche!

a-=10;

und noch mehr Nachrichten an Objekte gesendet.

btw. schau mal über den Tellerrand und guck dir mehr als C++ an, wenn du große Töne über OOP schwingen willst...

[Tellerrand]

Tim schrieb:

Mir kommt es so vor, als definiert jemand "Speiseeis" als "Mischung aus Wasser und Milch in festem Aggregatszustand mit Zucker und Zartbitterschokoladepartikeln mit definierter Größe"

Wenn ich Wasser und Milch mische, dazu Zucker und Zartbitterschokoladepartikel packe, dieses dann in einen festen Aggregatszustand versetze, dann will ich das selber nichtmehr essen.

Was ich damit sagen will ist, dass dies nicht unbedingt eine präzisiere Definition von Eis ist und da liegt in meinen Augen das Problem