Bibliotecas: Mapeado de Ficheros sin la DLL

[Automated-Trading]

Mapeado de Ficheros sin la DLL:

Clases (traducidas de C++ a MQL5) para trabajar con ficheros mapeados en memoria.

Autor: o_O

[Mykola Demko]

Alex, ¿habías previsto pasar un gestor de fichero virtual a otro hilo?

No lo he encontrado, si lo hay, por favor indícamelo.

ZY Pero en general, esto es algo bueno.

[---]

Urain:

Alex, ¿has pensado alguna vez en pasar el handle de un fichero virtual a otro hilo?

¿Cuál es el problema?

[Mykola Demko]

sergeev:
¿Cuál es el problema?

No hay problema, encapsulé el handle y lo pasé a otro objeto, todo funciona.

Sólo estoy buscando donde proporcionó para tal transferencia de acceso a archivos.

[---]

en la clase CMemMapApi el manejador de memoria debe ser almacenado por el programa que lo utiliza (este objeto).

y en CMemMapFile - el manejador se almacena en public m_hmem

[Mykola Demko]

sergeev:

en la clase CMemMapApi el manejador de memoria debe ser almacenado por el programa que lo utiliza (este objeto).

y en CMemMapFile - el handle se almacena en public m_hmem.

Entonces no entiendo algo muy bien :)

especificar después de cerrar el archivo se puede abrir en otro programa o

¿se destruye después de cerrar?

y cuando se destruye el archivo y se libera la memoria?

[Mykola Demko]

Urain:

Entonces no entiendo algo muy bien :)

especificar después de cerrar un archivo se puede abrir en otro programa o

¿se destruye después de cerrarlo?

¿y cuando se destruye el archivo y se libera memoria?

Aha descubierto, no se puede pasar asas, pero sólo hacer una nueva apertura en un nuevo hilo por nombre de archivo.

[---]

Urain:

Aha descubierto, no se puede pasar asas, pero acaba de hacer una nueva apertura en un nuevo hilo por nombre de archivo.

Bueno Nikolay, ¿por qué hice todo esto? :) por supuesto, de modo que diferentes programas pueden escribir / leer simultáneamente a un archivo común.

[Anatoli Kazharski]

sergeev:
Nikolay, ¿por qué hice todo esto? :) por supuesto, para que diferentes programas pudieran escribir/leer en un archivo común al mismo tiempo.

Alex, gracias por tu trabajo. No he tratado de usarlo todavía, ya que es un tema nuevo para mí, tengo que leer (Rashid sugirió artículos). Sólo una pregunta por el momento. En el título del tema se hace hincapié - sin DLL. Pero hay una apelación a kernel32.dll y msvcrt.dll. Así que esta solución no es adecuada para el Mercado?

[Mykola Demko]

tol64:
Alex, gracias por tu trabajo. No he tratado de usarlo todavía, ya que sigue siendo un tema nuevo para mí, tengo que leer (Rashid sugirió artículos). Pero aquí está una pregunta por el momento. En el título del tema se hace hincapié - sin DLL. Pero hay una apelación a kernel32.dll y msvcrt.dll. Entonces, ¿esta solución no es adecuada para el Mercado?

No es adecuada para el Market (aunque todavía está en cuestión), pero Renat dijo que pensaría en implementar tales cosas en el estándar MQL5.

En el titulo quise decir sin dlls autoescritas, despues de todo, las dlls estandar de Windows son mas seguras que las autoescritas.

[---]

Urain:

El título quería decir sin dlls autoescritas, después de todo, las dlls estándar de Windows son más seguras que las autoescritas.

Sí, quería decir sin dlls autoescritas. Y las estándar son seguras en el sentido de que todo el mundo sabe lo que hacen.
para el mercado esta solución (de acuerdo con las normas vigentes) no es adecuada.

pero el mercado (realmente espero) aceptará mi variante propuesta como básica - se puede publicar un Asesor Experto que llame a funciones de ex5-library.

Es decir, todas las llamadas dll se colocan en ex5, que no está expuesto en el mercado, pero se encuentra en el codebase o en el sitio del desarrollador.