¿Se demandará OOP en MQL5? - página 6
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
Si quieres, puedes encontrar OOP en BASIC, que también es un intérprete.
Creo que tenemos que esperar y ver la demanda de OOP en indicadores, Asesores Expertos y scripts. Y en el hecho de decidir cómo es realmente.
HideYourRichess писал(а) >>
Creo que hay que esperar a ver qué demanda de OOP habrá en indicadores, EAs y scripts. Y luego decidir cómo funciona realmente.
En este momento estoy tratando de automatizar la copia de los búferes de datos con todos ellos en los indicadores. Es un proceso duro, siempre me encuentro con problemas como la ausencia de referencias, constructores con parámetros (RAII es irrealizable), etc.
Y no estoy satisfecho con una cosa similar que viene con él. En absoluto.
C-4 escribió >>
Z.U. La mayoría de la gente asocia la POO con un lenguaje de programación concreto, el C++
¿Por qué, está mal implementado? En mi opinión, está muy bien implementado. Como en cualquier otro lenguaje normal orientado a objetos.
MQ5 es un OOP,
Pero es pobre en prestaciones.
La POO existe incluso en C, pero por alguna razón muchos no la conocen, lo que de nuevo habla de un conocimiento superficial.
Por favor, explique un poco más este punto.
Ahora estoy tratando de automatizar la copia de los datos del buffer con todo el acompañamiento en los indicadores. Va duro, es complicado, me choco constantemente con muros como la falta de referencias, constructores con parámetros (RAII es irrealizable), etc.
Y no estoy satisfecho con una cosa similar que viene con él. En absoluto.
A decir verdad, yo también lo intenté. No fue nada especial, sólo un escarceo. Lo dejé, no saqué nada bueno de ello. O bien tengo que volver a formarme mucho, o bien hay que ampliar la OOP. Todavía no se espera a ninguno de los dos. En general, pasé por encima del rastrillo, y no entendí si era tan tonto o si debía mandar tickets al soporte técnico, - renuncié a todo por el momento.
Por favor, puedo elaborar:
INCAPSULACIÓN:
struct mail
{
int zipcode;
char adr[50];
char comment[10];
...
}
POLIMORFISMO ESTÁTICO:
double d=3.12, c;
int i=5;
c=d+i;
POLIMORFISMO DINÁMICO:
void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *));
INCLAPSULACIÓN:
El mismo ejemplo que en el polimorfismo dinámico, en este caso la función qsort toma las propiedades de compare()
Por favor, puedo elaborar:
Algo así es lo que esperaba ver. Sólo se cuenta el polimorfismo estático. No veo ningún sentido en continuar la discusión sobre este tema (OOP en C) y no lo haré.
Pensé que realmente me sorprendería.
Resumiendo algunos resultados muy preliminares, podemos decir que la POO en la implementación de las metacomillas no es aceptada ni siquiera por los programadores experimentados. Tal vez sea por la aplicación. Tal vez haya que acostumbrarse a ello y la OOP sea realmente más conveniente. Pero hasta ahora tenemos lo que tenemos. Parece que es más conveniente sin ella. Es decir, probablemente puedas escribirlo, pero sólo por la POO, no por la usabilidad, la velocidad de escritura, por no hablar del rendimiento del propio código, que de todos modos será más lento contra el PP.
Tal es el caso...
¿Es realmente tan importante la necesidad de la POO (no importa quién entienda bajo esta abreviatura)? Para mí es mucho más importante qué nuevas funciones de comercio y servicios aparecerán, que facilitarán el trabajo del comerciante y del programador, y lo bien/completamente que se implementarán.
Si me muestras al menos diez certificados de cumplimiento de MQL5 con los estándares de la POO, pero sin la creación de objetos por indicadores ninguna POO te salvará de los entresijos de mostrar un simple texto en la pantalla. ¿De qué sirve un uso orgulloso de la POO, si ni siquiera se puede utilizar una rueda de muñeca común en este objeto gráfico? Un botón que funciona como una casilla de verificación, y la falta de un cuadro combinado estándar, de modo que, por ejemplo en un Asesor Experto sólo podría seleccionar el marco de tiempo para los cálculos, y la capacidad de agrupar varios objetos en uno. Ni siquiera estoy hablando del editor de formularios de diálogo, porque la plataforma está desarrollada para el auto-trading... :(
IMHO: En MQL5 sólo hay una versión (muy) truncada de las posibilidades inherentes a la POO clásica. Los desarrolladores han hecho un gran trabajo y seguramente simplifica la escritura de un código fuente, pero todo es en vano, y todavía quiero un taxi, y espero que los desarrolladores no empiecen a trabajar en MQL6 pronto, sino que trabajen fructíferamente mucho tiempo para "finalizar" MQL5 ;)
Pero, ¿es tan importante la exigencia de OOP (quien entienda este acrónimo)? Para mí es mucho más importante qué nuevas funciones de comercio y servicios aparecerán, que facilitarán el trabajo del comerciante y del programador, y lo bien/completamente que se implementarán.
Sí, por supuesto. Y se ha hablado mucho de esto en los hilos correspondientes. Me parece, por ejemplo, que MC, en lugar de resolver viejos problemas, sólo ha complicado su solución con innovaciones.
No estoy hablando de OOP ahora mismo. Pero la energía gastada en esta función bien podría haberse empleado en algo realmente útil y demandado.
Sí, por supuesto. Y se ha hablado mucho de ello en los hilos correspondientes. Me parece, por ejemplo, que el MC, en lugar de solucionar los viejos problemas, sólo ha complicado su solución con innovaciones.
No me refiero a la OLP ahora. Pero la energía que se gasta en esta oportunidad, sería muy posible gastarla en algo realmente útil y con demanda.
No es una pregunta sencilla, en realidad. De hecho. No vemos ningún rediseño en el servidor. Según información incompleta en Internet, es más fresco de lo que era. Ciertamente no es para nosotros, para los DT, pero por otro lado el servicio puede mejorar, en general.