Performancemythen?

Jester

Xin schrieb:

Da diese Definition allerdings bestenfalls Deppenfutter darstellt, damit die was haben, um es in der Luft zu zerreißen, bitte ich dafür um ein wenig Geduld.

Ja, das ist sicher ne gute Idee, vorsichtshalber schonmal alle eventuellen Kritiker als Deppen zu bezeichnen. Das überzeugt mich bereits jetzt.

Aber vermutlich liegt das daran, dass Du ja eh als einziger vernünftig mit Definitionen und Logik umzugehen weißt. Wer da widerspricht beweist nur seine Dummheit.

Xin schrieb:

TheTester schrieb:

Xin schrieb:

[...]Die Objekte stehen ja anscheinend nicht miteinander in Beziehung, es findet ja keine Vererbung statt.

Damit Objekte in einer Beziehung zueinander stehen muss keine Vererbungsbeziehung zwischen ihnen bestehen. Es gibt auch noch die einfache Assoziation, Aggregation und Komposition. Das die Sachen nicht das gleiche sind wird auch z.B. durch die Symbolik der UML deutlich.

Und haben diese Beziehungen etwas mit OOP zu tun?

Hallo MacFly, jemand zuhause? Du widerlegst meinen Codeschnipsel mit Argument A, jemand beweist, daß A gar nicht zutrifft, und Du fragst, was das mit OOP zu tun hat?
Das war ein integraler Bestandteil "unserer" Definition.

Xin schrieb:

Da diese Definition allerdings bestenfalls Deppenfutter darstellt, damit die was haben, um es in der Luft zu zerreißen, bitte ich dafür um ein wenig Geduld.

Viel schlimmer, die ganze Welt dreht sich um DICH! Die Deppen, Mathematikloser und Halbinformatiker hier werden DICH zerreißen, sie haben es alle nur auf DICH abgesehen!

otze

Xin schrieb:

Otzes Code:

class Tier 
{ 
    private: 
        string laut; 
    public: 
        Tier():laut("Hallo"){} 
        Tier(const string& laut):laut(laut){} 
      
        void gibLaut(){std::cout<<laut<<"\n";} 
}; 
class Katze: public Tier 
{ 
    public: 
        Katze():Tier("Miau"){} 
};

Ich les den rest mal nicht mehr, laut ist private. Dein beispiel geht durch keinen compiler!

//edit und du wirfst mir vor, dass ich deine postings nicht richtig lese? wo lebst du?

Xin schrieb:

Warum? Angst, etwas konkretes zu sagen, dass jemand anderer kritisieren könnte?

Nein, das ist pure Faulheit gepaart mit dem Wissen, dass ich mich in einige Definitionen und Entwicklungen der Geschichte noch einlesen müsste.

Ich weiß wie lang so eine Definition wird, wieviel Arbeit da einzelne Sätze machen können, usw.
Fängt ja schon damit an, warum der Begriff Klasse erst später der Objektorientierung hinzugefügt wurde, bzw. warum man den Begriff Klasse erstmal außen vor lassen sollte.
Warum ein if(Bedingung) then {Anweisungsblock} kein OO ist.
Oder auch warum Vererbung nicht unbedingt ein Grundstein der OOP ist.
...

Dafür würde ich mehrere Tage brauchen bis ich zufrieden bin und am Ende muss ich dann noch die Formulierungen so überarbeiten, dass sie eindeutig sind.
Da bin ich derzeit schlicht zu faul für.

Xin

otze schrieb:

Ich les den rest mal nicht mehr, laut ist private. Dein beispiel geht durch keinen compiler!

Hättest Du mal machen sollen.

Xin schrieb:

Allerdings spiele ich hier seit 3 Tagen den Erklärbär für's Forum

ne sorry du bist hier eher ne lachnummer des forums.

und gelegentlich möchte ich mich auch um andere Dinge kümmern.

dann schreib halt nicht so ellenlange posts, die am ende außer beleidigung und arroganz ja doch nix aussagen

TheTester

Xin schrieb:

TheTester schrieb:

Xin schrieb:

[...]
Die Objekte stehen ja anscheinend nicht miteinander in Beziehung, es findet ja keine Vererbung statt.

Damit Objekte in einer Beziehung zueinander stehen muss keine Vererbungsbeziehung zwischen ihnen bestehen. Es gibt auch noch die einfache Assoziation, Aggregation und Komposition. Das die Sachen nicht das gleiche sind wird auch z.B. durch die Symbolik der UML deutlich.

Und haben diese Beziehungen etwas mit OOP zu tun?

Wenn Vererbung etwas mit OOP zu tun hat, ja dann haben sie auch etwas mit OOP zu tun. Nur mit Vererbung allein lassen sich nicht alle Beziehungen von Objekten untereinander charakterisieren. Ich bin mit mir etwas uneins ob sie jedoch neben Vererbung einen echten Beitrag zur Def. leisten. Sie haben wohl etwas mit OOP zu tun aber ich glaube eher derart das sie, betrachtet von der Abstraktionsebene, niedriger angesiedelt sind als OO und deshalb von OO schon "impliziert" werden.

Wenn man es denn arg streng betrachtet würde wohl das Klassenkonzept, Vererbung und Polymorphie OO zur OO machen, da das die wesentlichen "Neuerungen" in den Entwurfskonzepten sind und Dinge wie funktionale Abstraktion, Datenabstraktion, abstrakte Datentypen durch den höheren Abstraktionsgrad schon enthalten sind (betrachtet auf die Evolution von Entwicklungskonzepten).

tt

otze

Xin schrieb:

otze schrieb:

Ich les den rest mal nicht mehr, laut ist private. Dein beispiel geht durch keinen compiler!

Hättest Du mal machen sollen.

gcc:

test.cpp:8: error: `std::string Tier::laut' is private
test.cpp:23: error: within this context

//edit den code mal her

#include <string>
#include <iostream>

using namespace std;
class Tier
{
    private:
        string laut;
    public:
        Tier():laut("Hallo"){}
        Tier(const string& laut):laut(laut){}

        void gibLaut(){std::cout<<laut<<"\n";}
};
class Katze: public Tier
{
    public:
        Katze():Tier("Miau"){}
};
int main()
{
  Tier* tier  = new Katze();
  tier->laut = "Iaaa Iaaa";
  tier->gibLaut();
}

Undertaker

vielleicht sollte mal jeder seine persönliche auffassung von OOP hier hinschreiben?
meine ist die:
sobald ein programm aus lauter autarken komponenten besteht, und der mensch diese irgendwie miteinander verknüpft und in beziehung bringt (völlig egal, ob er ganz archaisch 'methoden' aufruft und damit den kontrollfluss manuell festlegt oder die komponenten ein eigenleben haben und sich selbständig messages zuschieben), dann kommt dabei ein 'objektorientiertes programm' heraus (weil die vorgehensweise bei design und/oder programmierung sich an objekten orientiert hat). dazu muss man weder vererbung noch polymorphismus verwendet haben und die objekte müssen auch nicht unbedingt dingen aus der realen welt nachempfunden sein.
welche programmiersprache man benutzt hat, ist auch egal.
im gegensatz dazu, bei einem 'nicht-OO-programm', ist der programmierer damit beschäftigt, irgendwelche abläufe und algorithmen in die maschine zu stopfen, indem er hauptsächlich mit funktionen, schleifen, primitiven datentypen usw. hantiert. hierbei ist der 'instruction counter' dass maß aller dinge und sowas ist eben nicht-OOP.
so...der nächste bitte

Xin

otze schrieb:

Xin schrieb:

otze schrieb:

Ich les den rest mal nicht mehr, laut ist private. Dein beispiel geht durch keinen compiler!

Hättest Du mal machen sollen.

gcc:

test.cpp:8: error: `std::string Tier::laut' is private
test.cpp:23: error: within this context

[/cpp]

Man, man, man... Beschwer Dich nicht, dass ich Dir vorwerfe, dass Du die Postings nicht liest.
LIES DAS POSTING!

Ich mach's Dir einfacher, ich quote die wichtigen Stellen.

Aus dem gleichen Posting - nur eine Zeile hättest Du weiterlesen müssen:

Xin schrieb:

Edit: Ich ziehe das Ia zurück und behalte es für mich...

Ich habe meinen falschen Code drin gelassen, weil ich nicht einsehe, das Posting nachträglich zu verfälschen. Ich darf mal versehentlich ein "private" überlesen, das macht mich in meinen Augen nicht zum Totalversager. Ich kann dadrüber lachen, wenn ich Dir eine Grube grabe und selbst reinstolper.
Ich dachte, Du kannst vielleicht auch drüber lachen - sieht ja nicht so aus.

Zwei Postings weiter antworte ich auf Deine Änderung im Deinem Posting:

Xin schrieb:

Ich ändere mein Posting nicht, damit ich weiterhin belegen kann, dass wenn ich mich zum Esel mache, ich das wenigstens noch selbst merke

Ich lese hier alles. Und ich beantworte sehr viel und es tut mir leid, dass sich bei den vielen Antworten gelegentlich auch mal ein Flüchtigkeitsfehler einschleicht. ENTSCHULDIGE VIELMALS! Ich bin nicht perfekt, ich bin lediglich davon überzeugt, dass meine Definition von OOP besser ist als der Rest. Ich darf mich hier gegen nahezu alle verteidigen, während Du Dich das Privileg hast, Dich auf Dein eines kleines Posting zu konzentrieren und reihenweise derartige Postings hinterher schieben darfst, die überflüssig wären, würdest Du das eine Posting wirklich lesen, bevor Du antwortest.

Okay...?

In dem Posting, in dem Du das Lesen eingestellt hast, findest Du weiterhin die immernoch korrekte Antwort, warum Dein Vorschlag, leider noch kein OOP ist.

Xin

Undertaker schrieb:

vielleicht sollte mal jeder seine persönliche auffassung von OOP hier hinschreiben?
meine ist die:
sobald ein programm aus lauter autarken komponenten besteht, und der mensch diese irgendwie miteinander verknüpft und in beziehung bringt (völlig egal, ob er ganz archaisch 'methoden' aufruft und damit den kontrollfluss manuell festlegt oder die komponenten ein eigenleben haben und sich selbständig messages zuschieben), dann kommt dabei ein 'objektorientiertes programm' heraus (weil die vorgehensweise bei design und/oder programmierung sich an objekten orientiert hat). dazu muss man weder vererbung noch polymorphismus verwendet haben und die objekte müssen auch nicht unbedingt dingen aus der realen welt nachempfunden sein.

Frage: Definiere bitte das neu im Thread erschienene Wort "Komponente".
Ja, ich habe eine Vorstellung davon, aber das ist die Blackbox in Deiner Aussage. Deine Komponenten müssen objekt(-typ)orientiert sein, damit ich der Aussage (!=Definition) soweit zustimmen könnte.

Xin

Und nochmal ich: Folgendes sollte eigentlich vor otzes Posting stehen:

TheTester schrieb:

Xin schrieb:

Damit Objekte in einer Beziehung zueinander stehen muss keine Vererbungsbeziehung zwischen ihnen bestehen. Es gibt auch noch die einfache Assoziation, Aggregation und Komposition. Das die Sachen nicht das gleiche sind wird auch z.B. durch die Symbolik der UML deutlich.

Und haben diese Beziehungen etwas mit OOP zu tun?

Wenn Vererbung etwas mit OOP zu tun hat, ja dann haben sie auch etwas mit OOP zu tun. Nur mit Vererbung allein lassen sich nicht alle Beziehungen von Objekten untereinander charakterisieren. Ich bin mit mir etwas uneins ob sie jedoch neben Vererbung einen echten Beitrag zur Def. leisten.

Wenige Beleidigungen zuvor, schrieb "scrub_" noch dazu:

Scrub_ schrieb:

Hallo MacFly, jemand zuhause? [...]was das mit OOP zu tun hat?
Das war ein integraler Bestandteil "unserer" Definition.

Ich sehe den Beitrag nämlich jetzt auch nicht und aus Scrubs Beitrag lese ich grade auch nicht, wo er ihn sieht.
Darum fragte ich nach.

TheTester schrieb:

Sie haben wohl etwas mit OOP zu tun aber ich glaube eher derart das sie, betrachtet von der Abstraktionsebene, niedriger angesiedelt sind als OO und deshalb von OO schon "impliziert" werden.

Auf jeden Fall lassen sich mit ihr Beziehungen zu Objekten ausdrücken.
Jeder Mensch hat eine aggregative Beziehung zu seinem Herzen. Menschen verdauen, schlafen und pflanzen sich fort und Herzen pumpen. Obwohl eine aggregative Beziehung besteht, sehe ich hier keine sinnvolle Möglichkeit einen objektorientierten Algorithmus zu formulieren, der diese Beziehung ausnutzt.

Jeder Hand hat eine assoziative Beziehung zu seinen Menschen. Die Hände sind da. Sind die Hände weg, bleibt der Mensch trotzdem da. Ich wüßte jetzt nicht, wie ich das ausnutzen könnte.

Die interessante Beziehung für OO ist die "ist ein" Beziehung: die Vererbung. Ein Arbeitnehmener ist ein Mensch. Arbeitnehmer verdauen, schlafen und pflanzen sich fort, aber nur während Pausen und in der Freizeit.

TheTester schrieb:

Wenn man es denn arg streng betrachtet würde wohl das Klassenkonzept, Vererbung und Polymorphie OO zur OO machen, da das die wesentlichen "Neuerungen" in den Entwurfskonzepten sind und Dinge wie funktionale Abstraktion, Datenabstraktion, abstrakte Datentypen schon enthält.

Das Klassenkonzept ist nicht notwendig, lediglich die Klassifizierung, also eine Schnittstelle, damit Basis und Ableitung Basisdaten an identischer Stelle stehen haben, damit die Basisfunktionen (z.B. typeid()) die Basisinformationen auslesen können.

Undertaker schrieb:

vielleicht sollte mal jeder seine persönliche auffassung von OOP hier hinschreiben?
so...der nächste bitte

objektorientiert ist, wenn verschiedene objekte miteinander kummunizieren, d.h. nachrichten empfangen und versenden können. <- punkt

und xin, dein "diskussionstil" ist echt bissl ignor/arrogant

Xin

overtaker schrieb:

und xin, dein "diskussionstil" ist echt bissl ignor/arrogant

Inwiefern?
Weil ich meine Überzeugung nicht der Allgemeinheit anpasse? Wobei ich nicht weiß, wer hier jetzt die Allgemeinheitheit repräsentiert, man lässt mir ja genug Auswahl.
Sorry, wenn ich nicht überzeugt bin, kann ich meine Meinung nicht anpassen. Das ist nicht ignorant und auch nicht arrogant.

sowohl ignorant als auch arrogant ist z.b. dass du die hälfte der kritischen posts hier ignorierst weil du ihnen anscheinend nichts entgegenzusetzen hast und dann nur rumpflaumst

rüdiger

Xin schrieb:

Allerdings spiele ich hier seit 3 Tagen den Erklärbär für's Forum und gelegentlich möchte ich mich auch um andere Dinge kümmern. Was ist daran lächerlich?

Daran ist lächerlich, dass du glaubst du bist der Erklärbär. In der Sache gibt es eben kein ultimatives richtig. Genauso wie bei dem Thema warum die Farbe Blau "Blau" heißt. Du hast eben deine eigene Ansicht. Die sich aber einfach _nicht_ mit der Ansicht der Mehrheit deckt. Das ist ja auch vollkommen in Ordnung! Du kannst ja meinetwegen auch Grün zu Blau sagen. In beiden Fällen lohnt es sich imho nicht eine 30 Seiten Diskussion zu führen, bei denen mehrere Personen "ihre Hose runterlassen".

Komisch finde ich nur, dass der Graham Artikel hier vieles voraus gesehen hat...

btw. Bashar hat in einem älteren Thread mal eine ziemlich gute OOP-Definition geliefert. Die ging ungefähr in die Richtung: OO ist der Austausch von Nachrichten zwischen Objekten. Bin aber zu faul den Thread zu suchen. Das traf es aber ziemlich genau imho und deckte sich auch mit allen (mir bekannten) Objekt-Systemen.

rüdiger schrieb:

in die Richtung: OO ist der Austausch von Nachrichten zwischen Objekten.

steht doch da schon

overtaker schrieb:

objektorientiert ist, wenn verschiedene objekte miteinander kummunizieren, d.h. nachrichten empfangen und versenden können. <- punkt

!!!!!!!!!!!!!!11111111

rüdiger

wunderbar! Hatte wohl zu lange pause gemacht beim schreiben des Beitrags.

Aber die Definition trifft es imho am besten.

otze

ich zähle die argumente auf:
1.

Xin schrieb:

Dann zeig mir mal, wie Du einen String aufrufst, ohne einen Segmentation fault zu bekommen.

Wieso ist das denn anforderung, dass mans aufruft? mal davon ab, was für ein Aufruf sollte das sein? Was spricht gegen ein Objekt mit überladenem Operator()?
Wobei, eigentlich braucht man das nicht, denn es gibt viele OOP unterstützende Sprachen bei denen bei argumentlosen funktionen der operator() nicht verwendet werden muss/darf, die funktionen werden dann wie normale variablen verwendet. Sind in diesen Sprachen diese funktionen dann auch kein OO?

natürlich könntest du sagen: "Im ASM code muss ein funktionsaufruf zu finden sein", aber damit begiebst du dich auf dünnes eis. Manchmal kann der Compiler den funktionsaufruf rausoptierem, oder den code so schieben, dass inlining möglich ist. Natürlich kann der Compiler die ganze geschichte auch anders implementieren.

Muss man also den ASM output anschauen um zu wissen, ob eine bestimmte Stelle OO ist?

Meine Lösung ist kein gutes Beispiel, die Funktionszeiger sollten eigentlich statisch hinterlegt werden und nicht im Objekt auftauchen. Dann hat man virtual nachimplementiert.

Das ist compilerabhängig, was er draus macht. nebenbei sind deine beiden funktionen normalerweise auch statisch hinterlegt, namespaces sind syntaxzucker aber für den compiler in der codegenerationsphase absolut bedeutungslos.

//nachtrag
Und was ist eigentlich mit funktionsobjekten? ich kann hinter ihnen eine funktion aus deinem beispiel verstecken und bottom up übergeben. Das ist dann oop, weil der functor sich nur um die funktion kümmert. Andererseits könnte der functor auch einfach nur einen wert verwalten, und dann ist das wieder kein oop. verfahrene situation, oder?