Errores, fallos, preguntas - página 2636

 
Koldun Zloy:

No soy un desarrollador, pero voy a comentar.

Para un array estático, el compilador tiene que asignar un cierto número de bytes en memoria en tiempo de compilación.

¿Cuánta memoria debe asignar el compilador si row y col son desconocidos en tiempo de compilación?

Los valores iniciales sólo se utilizan si se omiten los parámetros al llamar. Los parámetros reales sólo se conocen en tiempo de ejecución.

Así que, sin trucos, aprende el idioma.

Esto es un poco irónico, pero es más bien un llamamiento al desarrollador.
Así que Zloy, no te lo tomes como algo personal.

Resulta que las matrices dinámicas sólo pueden manejarse mediante objetos o estructuras. Otra muleta se crea en general.
No hay punteros a variables en mql, así que tenemos que usar el enfoque de objetos donde los punteros están disponibles.
Por lo tanto, para utilizar las matrices dinámicas, un usuario debe conocer la POO y trabajar con punteros, y además, en ejecución MQL.
¿Cuántos de ellos tienen estos conocimientos? Tú mismo sabes la respuesta. No tengo ninguna dificultad para entender el enfoque de los objetos, pero para los que no conocen la POO
Crean un umbral artificial para el uso del lenguaje, en particular cuando se trata de matrices dinámicas.
En mi opinión, un desarrollador, por el contrario, debería estar interesado en facilitar el uso del lenguaje, en lugar de complicarlo.
En otras palabras, deben desarrollar aquellas funciones que sean necesarias para que el usuario trabaje cómodamente con el lenguaje.
Y más aún con las matrices, que son casi la base de los métodos numéricos.

Por esta razón, me gustaría pedirles que crearan funciones similares a ArrayResize, pero para matrices ArrayResizeMx(A, n, m),
y quizás también para las multidimensionales. En otras palabras, dar la posibilidad de trabajar con matrices no como con objetos, sino como con arrays habituales al estilo C.
Especialmente para la representación visual de las matrices, la función ArrayPrint(A, 0) imprime matrices a partir de matrices, no de objetos.

 
Roman:

Ya en 2012 se resolvió con éxito el problema de las matrices multidimensionales dinámicas...
Aquí hay un hilo relacionado:https://www.mql5.com/ru/forum/6729

Ahora se puede mejorar el código añadiendo soporte para las plantillas.

 
Sergey Dzyublik:

Ya en 2012 se resolvió con éxito el problema de las matrices multidimensionales dinámicas...
Aquí hay un hilo relacionado:https://www.mql5.com/ru/forum/6729

Ahora se puede mejorar el código añadiendo soporte para las plantillas.

Lee todo el hilo, por suerte es corto.
¡Así que el tema de arranque, y no reveló su hazaña!
Algún tipo de burla, cebó el tema y desapareció.
Y una vez más es una inmersión en la OLP, no se permite la entrada a nadie.
Yuri citó su propia solución, nadie sabe hasta qué punto es cierta.
Que tendremos que modificar y modificar. ¿Quién lo hará? Nadie, ya que aún no lo han completado.

Por eso necesitamos funciones que trabajen con matrices dinámicas de forma inmediata por parte del desarrollador.
El desarrollador conoce mejor el tema y la asignación de memoria sin wrappers se ve mucho mejor y más rápida.
Al menos una funciónArrayResizeMx(A, n, m, k) abriría la posibilidad de trabajar no con objetos sino con arrays al estilo C.

 
Roman:


Y esto es de nuevo una inmersión en la OOP, nadie puede entrar.

Romano:


Por lo tanto, para utilizar las matrices dinámicas el usuario debe conocer la POO y trabajar con punteros y en la ejecución MQL también.
¿Cuántos de ellos tienen esos conocimientos? Tú mismo sabes la respuesta. No tengo ninguna dificultad para entender el enfoque de los objetos, pero para los que no conocen la POO
Crean un umbral artificial para el uso del lenguaje, en particular cuando se trata de matrices dinámicas.
Me parece que el desarrollador, por el contrario, debería estar interesado en facilitar el uso del lenguaje, en lugar de complicarlo.

Puede que le sorprenda, pero los jóvenes programadores de hoy en día consideran que la programación OOP es más fácil que la programación procedimental.

Estás pensando en términos de hace 25 años. Los jóvenes de hoy absorben el OOP con la leche de su madre. Aprende OOP si quieres estar a la moda; de lo contrario no harás más que refunfuñar.

 
Nikolai Semko:

Puede que le sorprenda, pero los jóvenes programadores de hoy en día consideran que la programación OOP es más fácil que la programación procedimental.

¿tal vez comparado con la programación funcional?

 
Nikolai Semko:

Puede que le sorprenda, pero los jóvenes programadores de hoy en día consideran que la programación OOP es más fácil que la programación procedimental.

Estás pensando en términos de hace 25 años. Los jóvenes de hoy absorben el OOP con la leche de su madre. Aprende OOP si quieres estar en la tendencia, de lo contrario no harás más que refunfuñar.

Sí, entiendo la POO, pero no hasta el punto que me gustaría.
Esto no es una queja, sino una propuesta constructiva.
Para que el desarrollador no tenga que escribir una función para asignar dos mallocs, obligan a los usuarios a estudiar POO.
Esto es sin duda que el progreso, el desarrollo y la popularización del lenguaje. Puedes ver lo mucho que aman y entienden la OOP aquí.
Verás, Nikolay, todo lo que está envuelto es código innecesario para ser ejecutado - no creo que haya que explicar por qué.
No hace falta que te hable de los modernos compiladores de optimización: no sabemos qué instrucciones aplicarán.
Quizá también le sorprenda que incluso los programadores estadounidenses prefieran escribir en el estilo procedimental no porque la POO sea mala, sino porque el código es más sencillo y rápido.
Y si no hay tareas de objetos en el proyecto, para qué usar wrappers, que de alguna manera hay que entender, para los jóvenes ))
Así que no estoy de acuerdo contigo en que los jóvenes absorban con avidez la POO.

Estoy pensando en C, que es donde se construye la lógica del lenguaje mql.
C nació en 1972, así que tiene 48 años ))
Pero de todos modos C es uno de los lenguajes más rápidos. ¿Sabes por qué? Porque no tiene envolturas de clase.

 
Andrei Trukhanovich:

¿tal vez comparado con uno funcional?

Funcional desde el punto de vista del procedimiento :)

 
Petros Shatakhtsyan:

No creo que sea eso. Aquí hay un tema especial: https://www.mql5.com/ru/forum/40295

No lo he mirado del todo, sobre todo porque es para MQL4.

No creo que el servidor deba enviar cotizaciones de símbolos si el mercado está cerrado.

Mi robot no se ve realmente afectado por esto porque después de la "apertura" del mercado, cuando llegan los ticks, analiza la tendencia, sus retrocesos, y eso lleva algún tiempo. Durante este tiempo se abre el mercado.

Pero se interpone si queremos ejecutar manualmente algunas operaciones durante este tiempo. Si la ejecución se realiza en función del mercado, la solicitud queda pendiente hasta la apertura del mercado y, naturalmente, se ejecuta al precio actual.

Es evidente que falta la función directa que recibe el nombre del símbolo y devuelve verdadero/falso (mercado abierto/cerrado).

Hay una cita y una sesión de comercio. Busca, se ha explicado 20 veces.

 
Andrey Dik:

Por favor, añada otra insignia de algún tipo:

4. Dinero

Donde se mostraría la suma de todos los fondos recibidos en el día (mercado, autónomos, etc.), sería muy conveniente, y ahora para ello hay que ir al perfil, que vería el saldo disponible.

Si tanto y regularmente llega, puedes pedir un plugin para chrome ;)

 
Andrey Khatimlianskii:

Hay una sesión de cotización y otra de negociación. Búscalo, está todo masticado 20 veces.

Sólo me llevó unos días cambiar de VC++ a MQL5. Nunca he buscado nada durante tanto tiempo.

Si recibe el mensaje "Mercado cerrado" durante la negociación, debe tener una forma sencilla de determinar este estado, en lugar de escribir un código "kilométrico" y complicado.

No me des consejos así.

Razón de la queja: