Eine Frage an die OOP-Experten. - Seite 17
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Ich meine die Anzahl der Klassen. Jede Zeile ist 200 Zeilen lang.
Wie viel schwieriger wäre der Zugang? Ich habe einen globalen Kernel, der von überall aus sichtbar ist. Bei OOP müsste ich sie aufgeben. Wie würde ich dann mit Elementen in Windows arbeiten? Ich werde komatös, wenn ich versuche, es mir vorzustellen.))
Statische Klasse.
Vladimir Simakov:
А теперь к эффективности. Switch - это что в конечном итоге? Это последовательное сравнение параметра с константами. Внимание Петр, последовательное.
überhaupt nicht notwendig.
Das bedeutet nicht, dass Peter Recht hat oder dass der Schalter überall angebracht werden sollte, aber dennoch.
Ja, das ist richtig. In Bezug aufdie Geschwindigkeit ist es natürlich die schnellste Option in MQL. Der Zugriff auf dieKlassenobjekte in der verwalteten Umgebung erfolgt jedoch indirekt.
Richtig, mehr über diese Funktion. Sie haben einen monströs großen Schalter, mit dem Sie eine von einem Dutzend benötigten Funktionen auswählen können. Bei einem solchen Wechsel kann man sehr leicht einen Fehler machen, indem man versehentlich Code für einen der Zweige an die falsche Stelle schreibt.
Mit einer Überlastung sind die Dinge viel einfacher. Wir haben zehn verschiedene Nachkommen, und jedes Mal arbeiten wir mit EINER Klasse, und diese hat EINE überladbare Funktion. Wir können sie nicht versehentlich in eine andere Klasse schreiben, weil wir dafür eine ganz andere Datei öffnen müssen.
Außerdem ist das Parsen selbst in diesem sehr großen Schalter meiner Meinung nach viel anstrengender als das Öffnen der einen Klasse, die wir brauchen, und das anschließende Parsen nur einer Funktion.
Im Assembler-Code läuft die gesamte Handhabung dieses Schalters ohnehin auf denselben Schalter hinaus, der von diesem Zeiger abhängt. Aber im Falle von OOP ist dies alles vor dem Programmierer verborgen und beeinträchtigt seine Arbeit nicht. Ohne OOP müssen Sie damit umgehen.
Grob gesagt: Wenn Sie laufen, senden Sie in einer bestimmten Reihenfolge Signale an Ihre Muskeln, die diese bewegen. Aber auf der Ebene des Bewusstseins erinnert man sich einfach daran, welche Bewegung man machen muss. Hier ist OOP genau diese Art von "Erinnerung an die auszuführende Bewegung". Du "verstehst nicht, warum wir uns an die Bewegung erinnern müssen, wenn wir einen Haufen Muskeln und Nerven haben, die mit ihnen verdrahtet sind". nun... Ich habe schon oft gesagt, dass es für die Titanen des Gedächtnisses völlig ausreicht, sich zu merken, welche Muskeln in welcher Reihenfolge angespannt werden müssen, um loszulegen. Es hat keinen Sinn, sich an die ganze Bewegung zu erinnern. Für andere, die sich nicht so viel merken können, ist es viel sinnvoller, sich die ganze Bewegung zu merken, und was es mit den Muskeln auf sich hat, in welcher Reihenfolge sie angespannt werden und in welchem Ausmaß - es ist sinnvoller, das vor dem Verstand zu verbergen.
Überladene Funktionen sind für den Compiler einfach andere Funktionen und keine Schalter.
Wie viel schwieriger wäre der Zugang? Ich habe einen globalen Kernel, der von überall aus sichtbar ist. Bei OOP müsste ich sie aufgeben. Wie würde ich dann mit Elementen in Windows arbeiten? Ich werde komatös, wenn ich versuche, es mir vorzustellen.))
Warum sollte das so sein?
Der globale Kernel und OOP schließen sich nicht gegenseitig aus.
Nur Elemente in Fenstern sollten in Fensterklassen gekapselt sein und nicht "im Verborgenen liegen". Nur damit niemand versehentlich "an den falschen Ort" gerät. Es ist sehr einfach, eine Variable zu ändern und dabei einen Fehler bezüglich ihrer Position in einem riesigen globalen Array zu machen, während es viel schwieriger ist, die richtige Schnittstelle abzufragen und dann die gleiche Variable im richtigen Objekt zu ändern und dabei einen Fehler zu machen.
Überladene Funktionen sind für den Compiler einfach andere Funktionen und kein Schalter.
Und wie wird derjenige ausgewählt, der benötigt wird? Wir sprechen über virtuelle Funktionen und späte Bindung. Welche überladene Funktion wird aufgerufen? Dies wird durch den this-Zeiger bestimmt, der beim Aufruf implizit übergeben wird. Und wie wird diese Entscheidung Ihrer Meinung nach getroffen?
Und wie wird derjenige ausgewählt, den wir wollen? Es geht um virtuelle Funktionen und späte Bindung. Welche überladene Funktion wird aufgerufen? Dies wird durch den Zeiger this bestimmt, der implizit an den Aufruf übergeben wird. Und wie wird diese Entscheidung Ihrer Meinung nach getroffen?
Eigentlich hat Peter nicht von virtuellen Funktionen gesprochen.
Aber sie haben auch keine Schalter.
Eine Klasse, die über virtuelle Funktionen verfügt, hat eine virtuelle Funktionstabelle.
Und jedes Objekt dieser Klasse enthält eine implizite Variable - einen Zeiger auf die virtuelle Funktionstabelle.
Wenn eine oder alle virtuellen Funktionen im Nachkommen überschrieben werden, wird eine neue Tabelle erstellt, und die Nachkommeninstanzen enthalten einen Zeiger auf sie.
Eigentlich hat Peter nicht von virtuellen Funktionen gesprochen.
Aber sie haben auch keine Schalter.
Eine Klasse, die über virtuelle Funktionen verfügt, hat eine virtuelle Funktionstabelle.
Und jedes Objekt dieser Klasse enthält eine implizite Variable - einen Zeiger auf die virtuelle Funktionstabelle.
Wenn eine oder alle virtuellen Funktionen im Nachkommen überschrieben werden, wird eine neue Tabelle erstellt und Instanzen des Nachkommens enthalten einen Zeiger darauf.
Ganz genau. Ich frage, wie diese Tabelle funktioniert, denn im Assembler-Code ist es derselbe Schalter.
Und über "nicht über virtuelle Funktionen sprechen" - das ist so ähnlich wie "warum OOP"... Das heißt, es geht um virtuelle Funktionen und nicht um einfache identische Funktionsnamen mit unterschiedlichen Argumenten.
Ganz genau. Meine Frage ist also: Wie funktioniert genau diese Tabelle? In Assembler-Code ist es derselbe Schalter.
Nein. Es ist nur ein Array von Zeigern auf eine Funktion.
Der Assemblercode übernimmt eine Tabellenadresse aus dem Objekt.
Sie übernimmt die Adresse der Funktion an einer bestimmten Stelle.
Und es wird ein Sprung zu dieser Adresse gemacht.
Was ist mit "Ich habe nicht von virtuellen Funktionen gesprochen" - das meinte ich mit "warum OOP"... Das heißt, es geht um virtuelle Funktionen, nicht nur um gleichnamige Funktionen mit unterschiedlichen Argumenten.
Seiner Frage nach zu urteilen, sprach er von Funktionen mit identischen Namen.
Höchstwahrscheinlich ist er sich nicht einmal der virtuellen Funktionen bewusst.