Fehler, Irrtümer, Fragen - Seite 1016
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
Ja, danke, ich habe einen Fehler bei der Vereinfachung des Quellcodes gemacht - jetzt habe ich den Fehler anders formuliert
Um Verwirrung zu vermeiden, habe ich den vorherigen Beitrag gelöscht.Es ist schrecklich. Wirklich. Was für ein schreckliches Leben...
--
Hören Sie, was ist für Sie drin? Wenn es kein Geheimnis ist.
Sie schreiben Ihren Berater in Lisp, nicht wahr? Hut ab, aber ich schlage vor, Sie wechseln zu Haskell.
;-)
Wozu brauchst du es? Wenn es kein Geheimnis ist.
MQL5 hat keine Inline-Funktionen (in Form) und ich verwende stattdessen parametrische Makros.
Ja, ich benutze sie auch, nur nicht so gruselig nistend. ))))
Zu Ihrer Information: mql5 übersetzt alle kleinen Funktionen in Inline-Substitution, d.h. wir können davon ausgehen, dass das Schlüsselwort "inline" standardmäßig in jeder benutzerdefinierten Funktion enthalten ist.
Die Entscheidung, ein Makro zu ersetzen oder in eine Funktion zu kompilieren, wird letztlich vom Compiler getroffen (wie übrigens auch bei C++). Es macht also keinen Sinn zu versuchen, die Dinge auf diese Weise zu beschleunigen, da alle einfachen Funktionen ohnehin inlined sind.
// Und übrigens - mit Typkontrolle! :)
Als Referenz übersetzt mql5 alle kleinen Funktionen in Inline-Substitutionen, d.h. Sie können davon ausgehen, dass das Schlüsselwort "inline" standardmäßig in jeder Benutzerfunktion enthalten ist.
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
Dort soll B() in 1.mqh inline sein - aber alles zusammen - kompiliert nicht normal - nur separat. Der ServiceDesk verwies auf die Zweideutigkeit des Anrufs, ging aber nicht näher auf den Kern des Problems ein und empfahl, das Projekt anders zu organisieren. Wie könnte man es anders machen? Alles funktioniert nur, wenn ich die B()-Implementierung aus .mqh in .ex5 entferne. Und was ist dann das Inline-Formular?
Übrigens, in MQL4 funktioniert dieses Beispiel - ohne Fehler, obwohl B() nicht inline in der Tat, sondern in der Form - inline ist.
Und ich habe es nicht wegen der Geschwindigkeit getan, sondern aus Bequemlichkeit. Im Grunde genommen können sie inline sein, aber nicht in Form(!).
Und was ist mit dem Formular?
" Wer ist ein Studebaker? Ist das Ihr Studebaker-Verwandter? Dein Daddy ist ein Studebaker?"
Schwierigkeiten treten auf, wenn Sie inline in .mqh definieren und es dann in mehreren .ex5 verwenden.
Es gibt keine Schwierigkeiten, wenn man keine logischen Fehler macht und die Funktionsweise eines Compilers richtig versteht.
Ich werde jetzt versuchen, den Link zu finden.
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
Die Funktion B() ist hier im Wesentlichen inline
Ich habe es nicht geschafft, Fehler wie "zweideutiger Aufruf einer überladenen Funktion mit denselben Parametern" zu beseitigen - sie traten nur auf, wenn man sie in eine separate .ex5
Sie haben dort eine im Grunde unerkennbare Rekursion auf Quellcode-Ebene. Der Compiler hat Sie gnädigerweise abgewiesen, und zwar zu Recht. Sie versuchen, eine Verbindung mit der Inluder-Libu herzustellen, die das gleiche Inluder definiert, in das Sie kompilieren. Was wollen Sie also? Wenn Sie ein Compiler wären, was würden Sie tun?
Vielleicht ist das neu für Sie, aber eine in einer DLL geschriebene Inline-Funktion kann auf keinen Fall als Makro außerhalb dieser DLL verwendet werden. // Zur Laufzeit existiert der Quellcode nicht mehr
Die zweite Neuigkeit für Sie: alle Bibliotheken in mql(4, 5) sind dynamisch gelinkt. Das sind im Wesentlichen die DLLs.
Fazit: Sie haben versucht, von einer Lib auf sich selbst zu verweisen, auf sich selbst zu verweisen, auf sich selbst zu verweisen...... usw.
Zustimmen, es wäre viel schlimmer, wenn es alle ohne Einwände kompiliert, und dann zur Laufzeit die Lib versucht, sich rekursiv zu laden, bis es aus dem Speicher lief.... :))
?
Deshalb gibt es in C/C++ das Schlüsselwort inline
Ich bin mir sicher, dass sich das Beispiel im Link nicht in C++ kompilieren lässt.
// Ich bin zu faul, das nachzuprüfen. Es macht einfach keinen Sinn. Wenn ich nicht verstehe, wie man rekursiv organisierten Quellcode erstellt, wird der Compiler es auch nicht verstehen.
Übrigens, dieses Beispiel funktioniert in MQL4 - ohne Fehler, obwohl B() nicht inline, sondern in form - inline ist
Ich weiß es nicht. Obwohl... da es dort keine Funktionsüberladung gibt, versucht der Compiler vielleicht nicht, auf eine falsche Überladung hinzuweisen - er ignoriert einfach dummerweise wiederholte Definitionen.
Es kompiliert in MQL4 (!) und in C/C++, wenn Sie inline vor B() schreiben
Dort gibt es überhaupt keine Rekursion, im Gegenteil
int A( int ) und #define B() A( 0 )
Es ist sehr einfach dort - wenn Sie nicht zu faul sind - schauen Sie auf Ihren frischen Kopf - nur getrennte Deklaration und Implementierung von Funktionen :)
Dort soll B() in 1.mqh inline sein - aber alles zusammen wird nicht normal kompiliert - nur einzeln. ServiceDesk hat sich mit dem Hinweis auf die Unklarheit des Anrufs nicht tief in den Kern des Problems eingearbeitet und empfohlen, das Projekt anders zu organisieren. Und wie sonst?
Es funktioniert nur, wenn Sie die B()-Implementierung aus .mqh in .ex5 entfernen. Was ist dann das Inline-Formular?
Sie haben gerade Ihre eigene Frage beantwortet:
Das Problem liegt hier nicht in der Ungültigkeit von B(), sondern in seiner Neudefinition.
Es ist nur so, dass C/C++ versteht (mit dem inline-Schlüsselwort), dass dies keine Neudefinition ist, und MQL5 nicht, obwohl es durch den Namen des kompilierten Moduls und eines in #import angegebenen unterscheiden kann. Ich weiß nicht, wie MQL4 das versteht.
Kurz gesagt, Sie können keine Implementierung einer Funktion in .mqh definieren und sie ohne Probleme in einer beliebigen .ex5 verwenden.
Genau richtig - es ist nur so, dass C/C++ versteht, dass es sich nicht um eine Neudefinition handelt, und MQL5 tut das nicht.
C/C++ sind in der Lage, dies NUR beim Kompilieren einer statischen Lib zu verstehen, da die Informationen über den Quellennamen in der Objektdatei gespeichert sind (um eine Neukompilierung zu erkennen).
Bei dynamisch gelinkten Bibliotheken wird dies nicht funktionieren, und wenn doch, dann nicht wegen der Erkennung von Reimplementierungen, sondern wegen "Prioritätsregeln" für die Namensübereinstimmung von aktuellem Quelltext und DLL. Einige Sprachen haben solche Regeln (insbesondere Delphi, wahrscheinlich auch einige C/C++-Compiler).