Programación asíncrona y multihilo en MQL - página 5
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
El principal problema no está en el "...todavía tiene que aprender".
El principal problema es que cuantas más advertencias haya, mayor será el peligro de que se produzcan errores complicados, que no son fáciles de calcular.
Y todo esto es un dolor de cabeza adicional para los desarrolladores.
Además, es bueno evaluar si mucha gente necesita realmente este multihilo.
El problema principal no es "...aún por aprender".
El principal problema es que cuantos más trucos haya, mayor será el peligro de que se produzcan errores de bulto, que son muy difíciles de calcular.
Todo esto es un dolor de cabeza adicional para los desarrolladores.
Además, es bueno saber si muchos desarrolladores realmente necesitan el multithreading.
Bueno, una cerda y un caballo, entonces, y a por ellos... hacia el amanecer...
Lástima que mql no tenga esa función,
Ladirección propondrá desarrollar una función mql estándar para la programación asíncrona,
ya que hay problemas de hilos y sobre todo de seguridad.
Para el modo asíncrono creo que no hay obstáculos de seguridad.
Ayer estuve en casa de mi suegra, están renovando las paredes, ¿estás haciendo lo mismo? - ¡Abran las ventanas, ventilen las habitaciones!
No hay nada que se interponga. La tarea consistía en utilizar la WinAPI pura. ¡Sin ninguna dll casera !
El tema fue creado para discutir cuestiones de programación mql multihilo. Hoy tienes algún tipo de espíritu negativo, ¿qué tipo de inundación en el tema, que yo mismo creé?
¿Por qué WinAPI? Déjame contarte un secreto, CLR también es "puro Windows", el soporte nativo para las bibliotecas .NET con importación de funciones "inteligentes" fue añadido hace un año, conoces WinAPI, pero no puedes crear un hilo en .NET? )))))
Por favor, absténgase de hacer este tipo de comentarios.
Pues bien, un arado y un caballo, y adelante... hacia el amanecer...
Dimitri, ¿has probado a cultivar y cosechar con un arado y un caballo?
Hay tantas sutilezas como oportunidades de cometer errores. Pero cuesta mucho más si la cosecha muere y pasas hambre...
Hay problemas en todas partes, y hay que medir el beneficio contra el esfuerzo. En particular, con este multithreading. No veo dónde es tan directamente necesario.
No sólo he sugerido que el autor escriba su primer programa en puro WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
hay mucha información sobre este tema en la red - primero escriba usando archivos de cabecera listos (windows.h y demás), luego elimine estos archivos de cabecera y acérquese a la preciada WinAPI pura = un gran trozo de código que puede registrar proceso y ventana, que puede recibir eventos y manejarlos.... y será sólo una ventana trivial que no puede hacer nada útil, pero entenderá cuánto trabajo hay que hacer usando WinAPI
Lo probé hace unos 15 años (no lo recuerdo con exactitud, recuerdo que había una conexión dial-up) y de esta manera cualquier "soy ingeniero de software en casa de mi madre" debería pasar para deshacerse de las preguntas y el deseo de dar consejos a los programadores de sistemas - desarrolladores de compiladores
"habiendo ido por este camino", quedará claro de una vez el colosal trabajo de cientos de programadores de sistemas que escriben compiladores y librerías para ellos, quedará claro por qué se ha dotado a la velocidad de una cómoda funcionalidad para el usuario, para que cualquier programador de aplicaciones pueda leer la ayuda y "en 2 clics" obtener el resultado deseado
ZS: en general, la falta de experiencia, conocimientos y habilidades provocó otra distorsión cognitiva ))))
El problema principal no es "...aún por aprender".
El principal problema es que cuantos más trucos haya, mayor será el peligro de que se produzcan errores de bulto, que son muy difíciles de calcular.
Todo esto es un dolor de cabeza adicional para los desarrolladores.
Además, es bueno evaluar: ¿cuántos necesitan realmente este multihilo?
Dimitri, ¿has probado a cultivar y cosechar con un arado y un caballo?
Hay tantas sutilezas como oportunidades de cometer errores. Pero cuesta mucho más si la cosecha muere y pasas hambre...
Hay problemas en todas partes, y hay que equilibrar el beneficio obtenido y el esfuerzo gastado. En particular, con esto del multithreading. No veo dónde es tan directamente necesario.
¿Qué es un arado y un caballo? La pala de siempre.
Si queremos ser serios y maduros, la primera tarea, que sería útil mover a un hilo separado para el trabajo asíncrono es WebRequest, pero generalmente está bien, se puede vivir con eso también.
La segunda tarea es el entrenamiento de las redes neuronales, la auto-optimización incorporada en el Asesor Experto. Si fuera posible crear fácilmente hilos desde Expert Advisor, este tema recibiría un gran impulso de vida.
Si somos serios y maduros, la primera tarea que sería útil poner en un hilo separado para el trabajo asíncrono es WebRequest, pero en general servirá, y podemos vivir con ello.
La segunda tarea es el entrenamiento de las redes neuronales, la auto-optimización incorporada en el Asesor Experto. Si fuera posible crear fácilmente hilos desde un Asesor Experto, este tema tendría una buena inyección de vida.
Sólo en MQL, ambas tareas se resuelven lanzando automáticamente el Asesor Experto.
No sólo he sugerido que el autor escriba su primer programa en puro WinAPIhttps://www.mql5.com/ru/forum/318593/page2#comment_12565043.
hay mucha información sobre este tema en la red - primero escriba usando archivos de cabecera listos (windows.h y demás), luego elimine estos archivos de cabecera y acérquese a la preciada WinAPI pura = un gran trozo de código que puede registrar proceso y ventana, que puede recibir eventos y manejarlos.... y será sólo una ventana trivial que no puede hacer nada útil, pero entenderá cuánto trabajo hay que hacer usando WinAPI
Lo probé hace unos 15 años (no lo recuerdo con exactitud, recuerdo que había una conexión dial-up) y de esta manera cualquier "soy ingeniero de software en casa de mi madre" debería pasar para deshacerse de las preguntas y el deseo de dar consejos a los programadores de sistemas - desarrolladores de compiladores
"habiendo ido por este camino", quedará claro de una vez el colosal trabajo de cientos de programadores de sistemas que escriben compiladores y librerías para ellos, quedará claro por qué se ha dotado a la velocidad de una cómoda funcionalidad para el usuario, para que cualquier programador de aplicaciones pueda leer la ayuda y "en 2 clics" obtener el resultado deseado
ZS: en general, la falta de experiencia, conocimientos y habilidades provocó otra distorsión cognitiva ))))
Igor, no todo el mundo como tú tiene un título en programación. ¿Dónde te enseñaron tus profesores? Por ello, las calificaciones están fuera de lugar.
Por esta razón la idea de WinAPI puro se desdibuja, supuse que sería más simple, de lo que has descrito.
Yo era un total desconocido en la programación, y sólo gracias a mql empecé a aprender C/C++ sin profesores ni consejos.
Pero como puedes ver, he llegado a las necesidades asíncronas por mi cuenta. Sí, puede que no sepa algo, pero estoy aprendiendo todo lo que necesito.
Sí, no estoy familiarizado con la tecnología .NET y no quiero hacerlo, estoy harto de C#, cada uno tiene su propia portabilidad de lenguajes.
¿Dónde me has visto dar consejos a los desarrolladores? Se sugirió añadir a mql un conjunto de funciones estándar para trabajar con código asíncrono.
Se trata de una propuesta sensata, no sé por qué has reaccionado tan negativamente a ella... ¿O tal vez tu forma de hablar es siempre así?
Si usted no necesita esa funcionalidad, otros usuarios sí. Es como con la POO, no todo el mundo la usa, pero está ahí. La asincronía parece estar presente en muchos lenguajes ahora, pero no en mql.
¿Cómo es que mql es peor que otros lenguajes, que está privado de métodos asíncronos? La cuestión de los hilos está cerrada, mientras que la asincronía está implementada de forma inmediata.
Igor, no todo el mundo como tú tiene un título en programación. ¿Dónde te enseñaron tus profesores? Por eso la calificación está fuera de lugar.
Por esta razón la idea de WinAPI pura se desdibuja, supuse que sería más simple, de lo que has descrito.
Antes no estaba para nada familiarizado con la programación, y sólo gracias a mql empecé a aprender C/C++ sin necesidad de profesores ni consejos.
Pero, como puedes ver, he llegado a las necesidades asíncronas por mi cuenta. Sí, puede que no sepa algo, pero estoy aprendiendo todo lo que necesito.
Sí, no estoy familiarizado con la tecnología .NET, y no quiero hacerlo, estoy harto de C#, cada uno tiene su propia portabilidad de lenguajes.
¿Dónde me has visto dar consejos a los desarrolladores? Se ha propuesto añadir a mql un conjunto de funciones estándar para trabajar con código asíncrono.
Se trata de una propuesta sensata, no sé por qué has reaccionado tan negativamente a ella... ¿O tal vez tu forma de hablar es siempre así?
Si usted no necesita esta funcionalidad, otros usuarios sí. Creo que ahora todos los lenguajes tienen asincronía, pero mql no.
¿Cómo es que mql es peor que otros lenguajes, que está privado de métodos asíncronos? Bueno, la cuestión de los hilos está cerrada, pero la asincronía es factible.
En MQL5 existe la asincronía, por ejemplo,OrderSendAsync.
En cuanto a la interacción con la red o el sistema de archivos - utilizar WinAPI, escribí la solución anterior. Creo que todo está ahí para eso. Puedes leer cómo utilizar estos métodos en el sitio de Microsoft. ¿Qué más queda sin revelar?)