Sugestões para a sintaxe MQL - página 10

Novo comentário
 
É engraçado ler tudo isso. Lembro-me dos gritos dos antigos camaradas quando eles decidiram introduzir classes, "ponteiros" e estruturas na MQL. Eles costumavam escrever: "Você matou a MQL! Agora só os profissionais poderão escrever nele...". - e outros disparates. Agora eles estão gritando do outro lado: deixe-me ter um C++ completo enquanto o mega-sistema é impossível de codificar. Mas quem impede que todos vocês façam isso? Pegue C++ e siga seu caminho. A MQL é um pouco mais uma história e é ingênuo misturar o quente com o frio.
 

O que você está dizendo sobre C++... Se você não gosta de C++, leve C#. Eu o mencionei especificamente no meu post original e mais adiante nas discussões enfatizei-o. Muito do que foi sugerido diz respeito a ambos os idiomas.

Portanto, uma de duas coisas: ou você é contra o progresso em princípio ou apenas resmunga. Embora ambas as variantes também sejam possíveis

 
Alexey Navoykov:

...

O MetaTrader é um bom terminal. Mas infelizmente, a grande maioria de seus usuários ainda são perdedores e apostadores. A MQ fez um grande esforço para entrar no nicho do comércio inteligente, mas não teve sucesso. Os apostadores só precisam de um "poke" MT4 com algum "TrendLaser" multicolorido no gráfico. Eles não se importam com estruturas, classes, especialidades com declive, etc. Mas "uma ovelha magra" - é assim que nós vivemos. Portanto, nesta situação, não é economicamente viável desenvolver características lingüísticas da MQL5. Mas seria razoável flertar com a multidão, por exemplo, introduzir fechaduras no MT5 ou Open[0] em vez de CopyRates.

 

Na verdade, isto é um pouco estranho. Originalmente, a MQL foi criada como uma linguagem de aplicação para escrever estratégias comerciais. Portanto, não continha tudo o que a C++ tem. Mas com o tempo, as tarefas no comércio algorítmico se tornaram mais complicadas, e as pessoas procuram e esperam por acréscimos à linguagem. Assim, eles tendem a colocar tudo o que não foi intencionalmente acrescentado a ele. Ao fazer isso, o número de regras e o nível de complexidade do idioma aumentarão, tornando-se uma barreira para si mesmos. Mas, se eles estão dispostos a superá-los, não há como detê-los.

Para mim, o desenvolvimento é, antes de tudo, encontrar a maneira correta e mais fácil de implementar um pensamento. Como tal, as capacidades da velha linguagem são suficientemente boas, mas os programadores profissionais sentem nostalgia do amontoado de regras e pilhas de sintaxe. )) Bem, se isso lhes dá inspiração - por que não?

 
Реter Konow:

Ao mesmo tempo, o número de regras e o nível de complexidade do idioma aumentarão, tornando-se uma barreira para elas.

Por que uma barreira? Adicionar novas características não os impede de utilizar as antigas. Como regra, ninguém é obrigado a usar essas "complexidades".

Embora houvesse certamente períodos em que as regras estabelecidas eram subitamente alteradas sem piedade em benefício do C++, mas esse era o momento de seu rápido desenvolvimento. Agora a linguagem tem quase tudo e só restam pequenas modificações.

 

A propósito, eu pessoalmente sinto não só falta de melhorias, mas também redução das características linguísticas no último ano e meio. A construção mais funcional e estável foi 1554, datada de 14 de março de 2017.Depois disso, houve algum redesenho radical dos internos, e houve construções problemáticas com muitos bugs, alguns dos quais não foram corrigidos até hoje. No entanto, alguns dos bugs antigos foram corrigidos. Em geral, o nível de construções atuais de bugs provavelmente ganhou um pouco. Mas sobre funcionalidade...

Por exemplo, já escrevi sobre o corte da possibilidade de fundir arrays a tipos básicos. Outro corte foi a proibição de fundir estruturas simples entre si. Sim, elas foram substituídas por unidades, mas não cobrem as possibilidades dadas pelo molde que permitiram compensar os inconvenientes da funcionalidade regular. Dado que a MQL não possui interfaces para estruturas (já escrevi sobre isso), esta solução era uma boa 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 que uma barreira? Adicionar novas características não impede que você utilize as antigas. Como regra, ninguém é obrigado a usar essas "complexidades".

Embora houvesse tempos em que regras bem estabelecidas eram repentinamente reescritas sem piedade em nome do C++, mas esse era o momento de seu rápido desenvolvimento. Agora quase tudo está lá, restam apenas pequenas revisões.

Eu quis dizer uma barreira para aqueles que querem usar as novas regras e sintaxe por conta própria. Eles terão que escrever seus programas por mais tempo e demorar mais para compreendê-los. Será que isso tornará seus programas mais eficientes? - Nem por isso. Eles serão capazes de resolver um número maior de tarefas? - Nem por isso.

Uma vez eu sugeri em um fórum uma solução muito simples de uma tarefa que todos costumavam resolver com uma montanha de código. Era pequeno e rápido. Entretanto, todos não gostaram. Não tinha aquelas coisas de que eles gostavam. Todos os tipos degabaritos <nome datilografado T> e Func(IValueable<A> &a)

Ofereceram-me para usá-los todos. Quando perguntei "por quê?", ninguém explicou nada claro.


P.S. A explicação mais clara que recebi foi: "Seu código é feio". E outra coisa: "Você não entende o poder conceitual". Mas eu sou um desenvolvedor. Eu preciso de uma bela solução, não de um belo código.

 
Alexey Navoykov:

Sim, eles foram substituídos por sindicatos, mas não cobrem as possibilidades que foram proporcionadas pela conversão, o que permitiu compensar as deficiências da funcionalidade padrão. Dado que a MQL não fornece interfaces para estruturas (já escrevi sobre isso), esta solução era uma boa alternativa:

Isto 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; }
};

Mas o resultado, é claro, é diferente.

1...345678910
Novo comentário