![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Das ist die erste Frage.
Wie importiert man Funktionen aus 32-Bit-DLLs wie user32.dll usw. in eine 64-Bit-Anwendung? Oder gibt es für sie Kopien im System mit diesem Namen und es wird ein OOP-Space erstellt?
Nun, zunächst einmal haben x64-Systeme einen emulierten Start von x86-Programmen. Die Frage ist, wie man x64-Programme in x86 ausführen kann?
Vielleicht ist die Frage nicht über das Terminal überhaupt, sondern über einige knifflige Kompilierung von diesen sehr DLLs?
Die DLLs werden von der Windows-API betrieben, z. B. user32, kernel32, winmm, wininet im 32/64-Bit-Terminal.
Die Lösung des Problems scheint woanders zu liegen.
Die Frage ist, wie man x64-Programme in x86 ausführen kann?
Vielleicht ist die Frage nicht über das Terminal überhaupt, aber über einige knifflige Kompilierung dieser sehr DLLs?
Zum Beispiel funktionieren user32, kernel32, winmm, wininet in 32/64 Bit Terminals.
Die Lösung für dieses Problem scheint anderswo zu liegen.
Theoretisch können Sie also 32-Bit-DLLs dort und dort zum Laufen bringen.
Vielleicht ist es an der Zeit, die Entwickler anzurufen.
Vielleicht gibt es schlauere Wege der Kompilierung // Ich habe aufgehört, mit einer 32-Bit-DLL zu arbeiten, die auf "naive" Weise auf x64 kompiliert wurde. Jedenfalls gibt es Präzedenzfälle, die "existieren" (c).
Zum Beispiel user32, kernel32, winmm, wininet in einem 32/64-Bit-Terminal.
Also mach es in dieser Analogie... keine große Sache!... :-))
Ich werde es mir ansehen. ;)
Die einfachste Version für Ihren Fall.
Nun, für den einfachsten Fall, Kredit. "Ich schreibe dich auf" :)
Aus dem Gedächtnis, aber nicht sparsam, im Vergleich.
Ergebnis:
Die Differenz beträgt das 6-fache, wenn man berücksichtigt, dass ich einen Float-Puffer habe - das 3-fache. // Sie haben auch einen impliziten Speicherraub - Ihre Systemtabelle der Klassendeskriptoren (in diesem Beispiel) ist 1000*1000+1000, während meine 1 (!) ist.
Die Geschwindigkeit ist fast die gleiche.
Werden Sie schrumpfen? ;)
--
Ich habe gelogen, Ihre Unterklassen sind alle statisch, so dass der implizite Raub ein wenig übertrieben ist. Streichen Sie das. :)
Vielleicht ist es an der Zeit, die Entwickler anzurufen.
Die Systembibliotheksfunktionen für x86 (32-Bit)-Prozesse haben einen speziellen Wrapper, durch den sie an x64 weitergegeben, ausgeführt und wieder an x86 zurückgegeben werden.
Kurz und bündig.
Systembibliotheksfunktionen für x86 (32-Bit)-Prozesse haben einen speziellen Wrapper, durch den sie zu x64 übertragen, ausgeführt und wieder zu x86 zurückgeführt werden.
Ich danke Ihnen für die Informationen.
Können Sie mir sagen, wie Sie das auch selbst tun können? Geben Sie einfach einen Link an (falls verfügbar).
Werden Sie schrumpfen? ;)
Nein, ich verwende eindimensionale Arrays, wann immer es möglich ist.
GUT. Optimierungsfragen sind in diesem Fall zweitrangig, die Leistung wird ohnehin verteidigt.
--
Ich kann Ihnen das folgende Problem anbieten.
Array hat eine beliebige Dimensionalität (der Klarheit halber beschränken wir uns auf ^16).
Die Dimensionalität wird bei der Erstellung durch die Anzahl der Parameter festgelegt, wie bei üblichen Arrays.
XXArray xx2(5,7), xx5(12,12,16,16,8);
Sollte für alle Dimensions-Indexer funktionieren ( A[i][j][k][n][m]....)