Performancemythen?

[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

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

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

Shape in dem C++ Template Beispiel

Wo ist da ein abstraktes Konzept, dass nicht im Sourcecode vorkommt?

Ich pack den Code hier nochmal rein, damit wir überhaupt sicher sind, dass wir vom gleichen sprechen:

Xin schrieb:

Shade Of Mine schrieb:

Mir ist gerade langweilig, deshalb ein kleines Gedankenspielchen:

class Triangle {
public:
  void draw();
};

class Circle {
public:
  void draw();
};

template<typename Shape>
void foo(Shape* s) {
  s->draw();
}

Das ist ja kein OO Code, weil er statisch ist, nicht wahr?

Korrekt, kein OOP.

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.

In dem Fall bin ich wohl der Pedant ^^
Das ist okay, denn es stimmt hier ja. Ich möchte nur nebenher erwähnen, dass zwar scharfe gezogene Definitionen schätze, aber deswegen nicht grundsätzlich pedantisch bin.
Hier bin ich Pedant, solange niemand die Frage auf Seite 11 sinnvoll beantwortet oder es wenigstens versucht.

Tim schrieb:

Müssten diese nicht alle (den Matheloser Jester mal ausgenommen) den Weg der peinlichst genauen Definition gehen?

Ich habe keine Ahnung, ob Jester gut in Mathe ist oder war.

Ich weiß aber - und das nicht nur aus dem Thread - dass grade Informatiker nicht gewohnt sind, ihre Werkzeuge in Frage zu stellen und es vielen aus einem mir nicht erklärlichen Grund schwer fällt, sich alternativen Möglichkeiten zu öffnen.

Tim schrieb:

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?

Sie ist speziel, aber deswegen nicht unbrauchbar.

Wie otze ja zeigt, gibt es genug Möglichkeiten, manche Probleme auch "nicht objektorientiert" zu lösen.
Ich kann zwar nicht sagen, ob ein Library mit OOP entwickelt wurde oder nicht, aber das kann ich nach nach "schwammiger" Definition auch nicht zwangsläufig erkennen, wenn ich nur eine C-Fasade habe. Ob es intern mit Klassen realisiert wurde, kann man da nicht erkennen.

Was diesen Kritikpunkt angeht, ist die "schwammige" Definition genauso unbrauchbar.

[Xin]

rüdiger schrieb:

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.

Sorry, hier ist es leider schon vorbei.
Das ist Syntax, die Realität sieht auch bei a.foo(); so aus:

ClassOfA::foo( a );

Aufruf einer statischen Funktion, mit dem Objekt als erstem Argument.

Wenn a.foo() OOP ist, ohne virtuell zu sein, dann ist printf() ebenfalls OOP.

[finix]

Xin schrieb:

In dem Fall bin ich wohl der Pedant ^^
Das ist okay, denn es stimmt hier ja. Ich möchte nur nebenher erwähnen, dass zwar scharfe gezogene Definitionen schätze, aber deswegen nicht grundsätzlich pedantisch bin.

Wo ist sie denn, deine "scharfe gezogene Definition" von OOP?

Xin schrieb:

Hier bin ich Pedant, solange niemand die Frage auf Seite 11 sinnvoll beantwortet oder es wenigstens versucht.

Welche meinst du denn?

[Xin]

finix schrieb:

Xin schrieb:

In dem Fall bin ich wohl der Pedant ^^
Das ist okay, denn es stimmt hier ja. Ich möchte nur nebenher erwähnen, dass zwar scharfe gezogene Definitionen schätze, aber deswegen nicht grundsätzlich pedantisch bin.

Wo ist sie denn, deine "scharfe gezogene Definition" von OOP?

Du kannst sie auf den letzten ähh... 20-30 Seiten lesen.
Die 40 packen wir wohl noch ^^

Ich lege die Tage eine Zusammenfassung vor, die ich dann zur Diskussion stelle.

finix schrieb:

Xin schrieb:

Hier bin ich Pedant, solange niemand die Frage auf Seite 11 sinnvoll beantwortet oder es wenigstens versucht.

Welche meinst du denn?

Die Frage, die ich hustbaer stellte - sorry, war Seite 12:

xin schrieb:

hustbaer schrieb:

Wenn man diese Definition von OO(P) verwendet heisst das noch lange nicht dass man hier irgendwelche abstrakten Klassen, Polymorphie oder virtuelle Aufrufe braucht. Wenn ein Programm so entworfen ist dass "die Auswahl des auszuführenden Codes" immer zur Compile-Zeit erfolgen kann (ohne natürlich den "falschen" Code auszuwählen), dann ist das kein Grund warum das Programm nichtmehr "OO" wäre.

Und welche Begründung gibt es, es "OO" zu nennen?
Nachrichten gibt's in rein prozeduralen Sprachen, in C++ wird es in Funktionsaufrufen gehandhabt.
Man könnte auch überall, was da in Wirklichkeit ja auch steht, die Funktion korrekt ausschreiben:

tier.Tier::Funktion( typ Parameter )

Das unterscheidet sich von

tier_Funktion( Tier * tier, typ Parameter )

nicht. Die Methode heißt Tier::Funktion( Tier *, typ ). Wo ist der Unterschied zu "tier_Funktion( Tier *, typ )?
Es passiert dasselbe und es wird auch dasselbe übersetzt. Es ist in der Implementierung identisch. Es ist semantisch identisch, beides kann als Nachricht übermittelt werden und beides wird in C++ als Funktionsaufruf umgesetzt.
Warum ist das eine für Dich "OO" und das andere nicht? Wo beschreibt die Masse einen Unterschied, der den Namen "objekt orientiert" rechtfertigt?

...und beides wird in C++ als - statischer - Funktionsaufruf umgesetzt.

[Helium]

OK, ich habe ja lange tapfer durchgehalten, aber irgendwo auf seite 28 oder 29 bin ich ausgestiegen.

Ich weiß nicht, ob in den folgenden Seiten definiert wurde, was mit "reiner" OO gemeint ist, deswegen mache ich das noch eben und klinke mich dann volkommen aus.

Zunächst ein Bereich, in dem rein vs. unrein an der Tagesordnung steht: rein-funktionale Sprachen (Haskell, Clean, ...) vs. unreine (SML, O'Caml, ...). Rein Funktionale Sprachen kennen eben keinerlei imperative Konstrukte, wie Schleifen, etc. da sich der Zustand nicht ändern kann und Schleifen somit grundsätzlich entweder nie oder unendlich lang laufen würden.

Analog ist es mit der reinen Objektorientierung zu verstehen.
C++ verwendet z.B.

if (x > y)
   ...
else
   ...

Wohin rein-Objektorientierte Sprachen solche Konstrukte natürlich gar nicht kennen. Alles ist ein Objekt. Equivalent in Smalltalk:

(x > y) ifTrue: [...] ifFalse: [...].

Dem Objekt x wird die Nachricht > mit dem Argument y geschickt. Dieses Antwortet entweder mit einem Objekt des Typs "True" oder mit einem Objekt des Typs "False".
Beide implementieren die Methode "ifTrue:ifFalse": (Argumente werden hinter Doppelpunkte in den Funktionsnamen eingestreut). "True" implementiert sie so, dass sie dem ersten übergebenen Block die Nachricht "value" schickt und den zweiten ignoriert. "False" implementiert sie so, dass sie dem zweiten übergebenen Block die Nachricht "value" shickt und den ersten ignoriert. (Code-Blöcke sind natürlich auch Objekte, da alles ein Objekt ist und deswegen ist es kein Problem einen zu übergeben.)

Rein objektorientiert bedeutet also nicht durch nicht-Objektorientierte Konstrukte "verunreinigt".

So. Das wars von mir zu dem Thema.

[finix]

Xin schrieb:

finix schrieb:

Wo ist sie denn, deine "scharfe gezogene Definition" von OOP?

Du kannst sie auf den letzten ähh... 20-30 Seiten lesen.
Die 40 packen wir wohl noch ^^

Ich lege die Tage eine Zusammenfassung vor, die ich dann zur Diskussion stelle.

Äh, ja, das hört sich tatsächlich nach scharf gezogener Definition an. Ist denn nicht eine deiner Quellen online verfügbar, so dass du bis dahin auf diese verweisen könntest?

[Xin]

finix schrieb:

Xin schrieb:

finix schrieb:

Wo ist sie denn, deine "scharfe gezogene Definition" von OOP?

Du kannst sie auf den letzten ähh... 20-30 Seiten lesen.
Die 40 packen wir wohl noch ^^

Ich lege die Tage eine Zusammenfassung vor, die ich dann zur Diskussion stelle.

Äh, ja, das hört sich tatsächlich nach scharf gezogener Definition an. Ist denn nicht eine deiner Quellen online verfügbar, so dass du bis dahin auf diese verweisen könntest?

Jemand warf folgenden Link rein: Stroustrup: What is OOP?.
Der Link steht von meiner Seite nicht mehr zur Diskussion, wenn Du etwas dazu anmerken möchtest, blättere zurück, Du wärst vermutlich nicht der erste, der etwas dazu anmerkt.

Ich zitierte schon ein paar Sachen und ansonsten sagte ich auch schon, dass eine Zitatschlacht weder für die eine oder andere Seite ein Beweis darstellt.
Es zählt schließlich nicht, wieviele etwas sagen, sondern wie gut sie es begründen können.

Lass es mich anders formulieren: Das eigene Hirn zu nutzen bringt mehr, als Texte zu zitieren, ohne zu wissen, ob die jeweiligen Autoren ihr Hirn benutzt haben oder nur von jemand anderem abgeschrieben haben.

[Shade Of Mine]

[quote="Xin"]
Wo ist da ein abstraktes Konzept, dass nicht im Sourcecode vorkommt?

Ich pack den Code hier nochmal rein, damit wir überhaupt sicher sind, dass wir vom gleichen sprechen:

Xin schrieb:

Shade Of Mine schrieb:

Mir ist gerade langweilig, deshalb ein kleines Gedankenspielchen:

class Triangle {
public:
  void draw();
};

class Circle {
public:
  void draw();
};

template<typename Shape>
void foo(Shape* s) {
  s->draw();
}

Das Konzept hier ist Shape. Genau wie in Java oder sonstwo wo man eine abstrakte Klasse/Interface hätte. Lediglich manifestiert es sich nicht direkt im Code in form einer Klasse/Interface sondern viel mehr im Sinne eines abstrakten Konzepts.

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

Wo ist da ein abstraktes Konzept, dass nicht im Sourcecode vorkommt?

Ich pack den Code hier nochmal rein, damit wir überhaupt sicher sind, dass wir vom gleichen sprechen:

Shade Of Mine schrieb:

Mir ist gerade langweilig, deshalb ein kleines Gedankenspielchen:

class Triangle {
public:
  void draw();
};

class Circle {
public:
  void draw();
};

template<typename Shape>
void foo(Shape* s) {
  s->draw();
}

Das Konzept hier ist Shape. Genau wie in Java oder sonstwo wo man eine abstrakte Klasse/Interface hätte. Lediglich manifestiert es sich nicht direkt im Code in form einer Klasse/Interface sondern viel mehr im Sinne eines abstrakten Konzepts.

Ich sehe da nichts abstraktes?! Das alles statisch.
Oder glaubst Du, dass ein Algorithmus dynamisch wird, weil Teile des Programms über ein Template erzeugt wurde?

Wenn Du in C++ etwas abstraktes formulieren willst, dann musst Du sowas formulieren:

class Figure
{
  public:
    virtual void draw() = 0;  // pure virtual == abstract
}

class Triangle : public Figure {
public:
  void draw();
};

class Circle : public Figure {
public:
  void draw();
};

template<typename Shape>
void foo(Shape* s) {
  s->draw();
}

Und damit ist es jetzt auch OOP.

Entweder verstehe ich nicht, was Du unter "Abstrakt" verstehst oder Du kommst in C++ um virtual nicht herum.

[dv_]

Xin schrieb:

Wenn a.foo() OOP ist, ohne virtuell zu sein, dann ist printf() ebenfalls OOP.

a.foo() ist OOP, weil die Funktionalität "foo" mit Daten zum Objekt "a" zusammengeführt sind. Bei printf gibt es keine Zusammenführung mit irgendwas.

Ich sehe da nichts abstraktes?! Das alles statisch.
Oder glaubst Du, dass ein Algorithmus dynamisch wird, weil Teile des Programms über ein Template erzeugt wurde?

Lerne generische Programmierung.

[rüdiger]

Xin schrieb:

rüdiger schrieb:

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.

Sorry, hier ist es leider schon vorbei.
Das ist Syntax, die Realität sieht auch bei a.foo(); so aus:

ClassOfA::foo( a );

Aufruf einer statischen Funktion, mit dem Objekt als erstem Argument.

Wenn a.foo() OOP ist, ohne virtuell zu sein, dann ist printf() ebenfalls OOP.

foo ist eine Nachricht an a. Was der Compiler daraus macht ist egal. Ganz zu schweigen davon, dass du das nicht beurteilen kannst, da du ja nicht weißt was a ist. Vielleicht ist es ja sogar eine Nachricht die nicht akzeptiert wird, was man wegen dem statischen OOP bei C++ ja zur Compilezeit erfährt. Was aber nicht bei jeder Sprache so seien muss! (Tellerrand Problematik)

Meinetwegen kann der Compiler aus der Nachricht die ich an das Objekt Schicke auch Senf mit Soße oder Speiseeis oder ne Birne machen. Hauptsache das Ergebnis stimmt.

(ob es nun ein call 0xAFFE oder ein call %eax ist, interessiert mich nicht (Ausnahme ist natürlich µOptimierung))

Was hat printf damit zu tun? Wo siehst du da Nachricht und Objekt?