![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Et donc il y a la question numéro un.
Comment importer des fonctions de dlls 32 bits comme user32.dll etc. dans une application 64 ? Ou bien existe-t-il des copies pour eux dans le système avec ce nom et un espace OOP est créé ?
Tout d'abord, les systèmes x64 ont un lancement émulé des programmes x86. La question est de savoir comment exécuter des programmes x64 en x86 ?
Peut-être que la question n'est pas du tout liée au terminal mais à une compilation délicate de ces mêmes DLLs ?
Les DLL sont alimentées par l'API Windows, par exemple user32, kernel32, winmm, wininet dans le terminal 32/64 bit.
La solution du problème semble se trouver ailleurs.
La question est de savoir comment exécuter des programmes x64 en x86 ?
Peut-être que la question n'est pas du tout liée au terminal, mais à une compilation délicate de ces mêmes DLLs ?
Par exemple, user32, kernel32, winmm, wininet fonctionnent dans un terminal 32/64 bits.
La solution à ce problème semble se trouver ailleurs.
Donc, théoriquement, vous pouvez faire fonctionner des DLL 32 bits ici et là.
Il est peut-être temps d'appeler les développeurs.
Il existe peut-être des méthodes de compilation plus astucieuses // J'ai cessé de travailler avec une DLL 32 bits compilée de manière "naïve" sur x64. Quoi qu'il en soit, il y a des précédents qui "existent" (c).
Par exemple, user32, kernel32, winmm, wininet dans le terminal 32/64 bits.
Alors faites-le dans cette analogie... pas de problème !... :-))
Je vais regarder. ;)
La version la plus simple pour votre cas.
Eh bien, pour le cas le plus simple, le crédit. "Je vous écris" :)
De mémoire, mais avec parcimonie, en comparaison.
résultat :
La différence est de 6 fois. En tenant compte du fait que j'ai un tampon flottant - 3 fois. // Vous avez également un vol de mémoire implicite - votre tableau système de descripteurs de classe (dans cet exemple) est de 1000*1000+1000, alors que le mien est de 1 ( !).
La vitesse est presque la même.
Allez-vous rétrécir ? ;)
--
J'ai menti, vos sous-classes sont toutes statiques, donc le vol implicite est un peu exagéré. Grattez ça. :)
Il est peut-être temps d'appeler les développeurs.
Les fonctions de la bibliothèque système pour les processus x86 (32 bits) ont une enveloppe spéciale par laquelle elles sont transmises à x64, exécutées et renvoyées à x86.
En bref.
Les fonctions de la bibliothèque système pour les processus x86 (32 bits) ont un emballage spécial, par lequel elles sont transférées vers x64, exécutées et renvoyées vers x86.
Merci pour ces informations.
Pouvez-vous m'indiquer comment faire de même sur votre propre site ? un lien (si disponible).
Allez-vous rétrécir ? ;)
Non, j'utilise des tableaux unidimensionnels chaque fois que c'est possible.
OK. Les questions d'optimisation sont secondaires dans ce cas, l'exploit est de toute façon défendu.
--
Je peux vous proposer le problème suivant.
Le tableau a une dimensionnalité arbitraire (limitons-la à ^16 pour plus de clarté).
La dimensionnalité est définie à la création par le nombre de paramètres, comme pour les tableaux habituels.
XXArray xx2(5,7), xx5(12,12,16,16,8);
Devrait fonctionner pour tous les indexeurs de dimensions ( A[i][j][k][n][m]....)