Bibliothèque: Mappage de fichiers sans DLL

Nouveau commentaire
 

Mappage de fichiers sans DLL:

Classe MQL5 qui fonctionne directement avec la cartographie, sans utiliser une DLL écrite par l'utilisateur.

Author: ---

 

Alex, avez-vous envisagé de passer un gestionnaire de fichier virtuel à un autre thread ?

Je ne l'ai pas trouvé, si c'est le cas, merci de me l'indiquer.

ZY Mais en général, c'est une bonne chose.

 
Urain:

Alex, avez-vous déjà envisagé de passer le handle d'un fichier virtuel à un autre thread ?

Quel est le problème ?
 
sergeev:
Quel est le problème ?

Pas de problème, j'ai encapsulé le handle et je l'ai passé à un autre objet, tout fonctionne.

Je cherche juste à savoir où vous avez prévu un tel transfert d'accès à un fichier.

 

dans la classe CMemMapApi, l'identifiant de la mémoire doit être stocké par le programme qui l'utilise (cet objet).

et dans la classe CMemMapFile - l'identifiant est stocké dans l'objet public m_hmem

 
sergeev:

dans la classe CMemMapApi, l'identifiant de la mémoire doit être stocké par le programme qui l'utilise (cet objet).

et dans la classe CMemMapFile - l'identifiant est stocké dans l'objet public m_hmem.

Je n'ai donc pas bien compris :)

Je ne sais pas si l'on peut spécifier qu'après avoir fermé le fichier, il peut être ouvert dans un autre programme ou s'il est détruit après avoir été fermé.

est-il détruit après la fermeture ?

Et quand le fichier est détruit et que la mémoire est libérée ?

 
Urain:

Alors je n'ai pas bien compris :)

Je précise qu'après la fermeture d' un fichier, celui-ci peut être ouvert dans un autre programme ou

est-il détruit après la fermeture ?

Et quand le fichier est détruit et que la mémoire est libérée ?

Aha j'ai compris, on ne peut pas passer des handles, mais juste faire une nouvelle ouverture dans un nouveau thread par le nom du fichier.
 
Urain:

Aha, j'ai compris, on ne peut pas passer des handles, mais juste faire une nouvelle ouverture dans un nouveau thread par nom de fichier.
Alors Nikolay, pourquoi j'ai fait tout ça ? :) Bien sûr, pour que différents logiciels puissent écrire/lire simultanément dans un fichier commun.
 
sergeev:
Nikolay, pourquoi ai-je fait tout cela ? :) Bien sûr, pour que différents logiciels puissent écrire/lire dans un fichier commun en même temps.
Alex, merci pour votre travail. Je n'ai pas encore essayé de l'utiliser, car c'est un nouveau sujet pour moi, j'ai besoin de lire (les articles suggérés par Rashid). J'ai juste une question pour l'instant. Dans le titre du sujet, il est souligné - sans DLL. Mais il y a un appel à kernel32.dll et à msvcrt.dll. Cette solution n'est donc pas adaptée au marché ?
 
tol64:
Alex, merci pour votre travail. Je n'ai pas encore essayé de l'utiliser, car c'est encore un nouveau sujet pour moi, j'ai besoin de lire (les articles suggérés par Rashid). Mais voici une question pour le moment. Dans le titre du sujet, il est souligné - sans DLL. Mais il y a un appel à kernel32.dll et à msvcrt.dll. Cette solution n'est donc pas adaptée au marché ?

Elle n'est pas adaptée au marché (bien qu'elle soit encore en question), mais Renat a dit qu'il penserait à mettre en œuvre de telles choses dans la norme MQL5.

Dans le titre, je voulais dire sans dlls auto-écrites, après tout, les dlls standard de Windows sont plus sûres que les dlls auto-écrites.

 
Urain:

Le titre signifiait sans dlls auto-écrites, après tout, les dlls standard de Windows sont plus sûres que les dlls auto-écrites.

Oui, je voulais dire sans dll auto-écrites. Et les dll standard sont sûres dans le sens où tout le monde sait ce qu'elles font.
Pour le marché, cette solution (selon les règles existantes) n'est pas appropriée.


Mais le marché (je l'espère vraiment) acceptera la variante de base que je propose : vous pouvez publier un conseiller expert qui appelle des fonctions de la bibliothèque ex5.

En d'autres termes, tous les appels de dll sont placés dans ex5, qui n'est pas exposé sur le marché, mais se trouve soit dans la base de code, soit sur le site du développeur.

123456789101112
Nouveau commentaire