Sugerencias para la sintaxis MQL - página 10

Nuevo comentario
 
Es curioso leer todo esto. Recuerdo los gritos de los viejos compañeros cuando decidieron introducir clases, "punteros" y estructuras en MQL. Solían escribir: "¡Has matado a MQL! Ahora sólo los profesionales podrán escribir en él...". - y otras tonterías. Ahora gritan desde el otro lado: déjenme tener un C++ con todas las funciones, mientras que el megasistema es imposible de codificar. Pero, ¿quién les impide hacerlo? Toma C++ y sigue tu camino. El MQL es un poco otra historia y es ingenuo mezclar lo caliente y lo frío.
 

Si no te gusta C++, coge C#. Lo mencioné específicamente en mi post original y más adelante en las discusiones lo subrayé. Muchas de las cosas sugeridas se refieren a ambos lenguajes.

Así que una de dos: o estás en contra del progreso en principio o simplemente refunfuñas. Aunque ambas variantes también son posibles

 
Alexey Navoykov:

...

MetaTrader es un buen terminal. Pero, por desgracia, la gran mayoría de sus usuarios siguen siendo perdedores y jugadores. MQ ha hecho un gran esfuerzo por entrar en el nicho del comercio inteligente, pero no lo ha conseguido. Los apostadores sólo necesitan un "pinchazo" de MT4 con algún "TrendLaser" multicolor en el gráfico. No les importan las estructuras, las clases, las especialidades con declinación, etc. Pero "un vellón de una oveja delgada" - así es como vivimos. Por lo tanto, en esta situación no es económicamente viable desarrollar las características del lenguaje en MQL5. Pero sería razonable coquetear con la multitud, por ejemplo introducir bloqueos en MT5 o Open[0] en lugar de CopyRates.

 

En realidad, esto es un poco extraño. Originalmente, MQL se creó como un lenguaje de aplicación para escribir estrategias de trading. Por lo tanto, no contenía todo lo que tiene C++. Pero con el tiempo, las tareas en el comercio algorítmico se complicaron, y la gente busca y espera adiciones al lenguaje. Por lo tanto, tienden a poner todo lo que intencionalmente no se agregó a ella. Al hacerlo, el número de reglas y el nivel de complejidad de la lengua aumentarán, convirtiéndose en una barrera para ellos mismos. Pero, si están dispuestos a superarlos, no hay quien los detenga.

Para mí, el desarrollo consiste, ante todo, en encontrar la forma correcta y más fácil de aplicar una idea. Así, las capacidades del antiguo lenguaje son suficientemente buenas, pero los programadores profesionales sienten nostalgia por el montón de reglas y los montones de sintaxis. )) Si les sirve de inspiración, ¿por qué no?

 
Реter Konow:

Al mismo tiempo, el número de reglas y el nivel de complejidad de la lengua aumentarán, convirtiéndose en una barrera para ellos.

¿Por qué una barrera? Añadir nuevas funciones no impide utilizar las antiguas. Por regla general, nadie está obligado a utilizar estas "complejidades".

Aunque ciertamente hubo periodos en los que las reglas establecidas fueron alteradas sin piedad en beneficio de C++, pero esa fue la época de su rápido desarrollo. Ahora el lenguaje lo tiene casi todo y sólo quedan pequeñas modificaciones.

 

Por cierto, personalmente siento no sólo la falta de mejoras, sino también la reducción de las características del lenguaje en el último año y medio. La build más funcional y estable fue la 1554, del 14 de marzo de 2017.Después de eso hubo un rediseño radical de las internas, y hubo builds problemáticos con muchos bugs, algunos de los cuales no han sido corregidos hasta el día de hoy. Sin embargo, algunos de los antiguos bugs fueron corregidos. En general, el nivel de bugs de los builds actuales es probablemente un poco mejor. Pero sobre la funcionalidad...

Por ejemplo, ya escribí sobre el recorte de la posibilidad de fundir arrays a tipos básicos. Otro recorte fue la prohibición de fundir estructuras simples entre sí. Sí, se sustituyeron por unidades, pero no cubren las posibilidades que daba el fundido que permitía compensar los inconvenientes de la funcionalidad regular. Dado que MQL no tiene interfaces para estructuras (ya he escrito sobre ello), esta solución era una buena alternativa:

template<typename T>
struct IValueable
{ 
  double Value() const { return ((T)this).GetValue(); }
 protected:
  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

  A(double value) { _value=value; }
  
  double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print(a.Value()); }


void OnStart()
{
  A a(10);
  Func(a);
}
 
Alexey Navoykov:

¿Por qué una barrera? Añadir nuevas funciones no impide utilizar las antiguas. Por regla general, nadie está obligado a utilizar estas "complejidades".

Aunque, por supuesto, hubo momentos en los que reglas bien establecidas se reescribieron de repente sin piedad en aras del C++, pero esa fue la época de su rápido desarrollo. Ahora casi todo está ahí, sólo quedan pequeñas revisiones.

Me refería a una barrera para aquellos que quieran utilizar las nuevas reglas y la sintaxis por su cuenta. Tendrán que escribir sus programas durante más tiempo y tardarán más en entenderlos. ¿Hará esto que sus programas sean más eficientes? - La verdad es que no. ¿Serán capaces de resolver un mayor número de tareas? - La verdad es que no.

Una vez sugerí en un foro una solución muy sencilla de una tarea que todo el mundo solía resolver con una montaña de código. Era pequeño y rápido. Sin embargo, no le gustó a todo el mundo. No tenía esas cosas que les gustaban. Todo tipo deplantillas<typename T> yvoid Func(IValueable<A> &a)

Me ofrecieron usarlos todos. Cuando pregunté "¿por qué?" nadie me explicó nada claro.


P.D. La explicación más clara que recibí fue: "Tu código es feo". Y otra cosa : "No entiendes el poder conceptual". Pero soy un desarrollador. Necesito una solución bonita, no un código bonito.

 
Alexey Navoykov:

Sí, fueron sustituidos por uniones, pero no cubren las posibilidades que ofrecía la conversión, que permitía suplir las carencias de la funcionalidad estándar. Dado que MQL no proporciona interfaces para las estructuras (ya he escrito sobre ello), esta solución era una buena alternativa:

Esto se compila.

#include <TypeToBytes.mqh>

template<typename T>
struct IValueable
{ 
  uchar Tmp;
  double Value() const { return (_C(T, this)).GetValue(); }
 protected:
//  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

//  A(double value) { _value=value; }
  void Set( double value ) { _value=value; }
  
  double GetValue() const { return _value; }
};

Pero el resultado, por supuesto, es diferente.

1...345678910
Nuevo comentario