OOP, modelos e macros em mql5, sutilezas e usos - página 6

Novo comentário
 
Alexey Viktorov:

Aqui vamos nós.

Então todos os seus códigos são feitos em muletas? Não é nada pessoal.
Sim, aproximadamente. Pois a MQL não tem OOP completo. Além disso, há muitos bugs, que eu reporto regularmente, mas sem sucesso. E eu tenho que me defender contra os bugs com muletas, o que posso fazer.
 

Eis como o fazemos.

Se a variável estática for inicializada com constante, esta inicialização será feita na etapa de inicialização global, como antes
Caso contrário (inicialização por chamada ou variável), a variável estática será inicializada na primeira referência (será como em C++), essa referência em si será envolvida em uma condição com variável/bandeira global implícita, por exemplo

para o código MQL:

class CFoo { };

void func(bool f)
  {
   if(f)
     {
      static CFoo foo;
      foo.MakeMeHappy();
     }
  }

Será gerado o seguinte pseudo-código

CFoo static_func_foo={}; // zeromem only
bool static_func_foo_init=false;

void func(bool f)
  {
   if(f)
     {
      if(!static_func_foo_init)
        {
         static_func_foo.CFoo();  // constructor call
         static_func_foo_init=true;
        }

      static_func_foo.MakeMeHappy();
     }
  }
 
Alexey Navoykov:

Você ainda terá que separá-los de alguma forma na função.

Não necessariamente e nem sempre. Não vou dar exemplos, para que não se desperdice o fio.

 
Ilyas:

Eis o que vamos fazer.

Ótimas notícias! Afinal, os deuses ouviram nossas preces).
 
Alexey Navoykov:
Sim, aproximadamente. Pois a MQL não tem OOP completo. Além disso, há muitos bugs, que eu reporto regularmente, mas sem sucesso. E contra os bugs eu tenho que me defender com muletas, o que eu posso fazer.

Você me confundiu a todos. Se em ... leia suas palavras

Fórum sobre comércio, sistemas automatizados de comércio e testes estratégicos

Peculiaridades de mql5, dicas e truques

Alexey Navoykov, 2019.01.25 11:44

Se os parâmetros são de tipos diferentes, é razoável fazer vários métodos sobrecarregados com os tipos correspondentes. Você tem que compartilhá-los em funções de qualquer maneira, por isso é melhor dividi-los em funções separadas, do que fazer uma bagunça, que além do mais leva ao tipo anônimo, ou seja, você pode erroneamente passar qualquer coisa para dentro dela e obter um erro de compilação dentro da biblioteca, que não é bom, ou pode até não obter, o que é duplamente ruim).

Em resumo, as funções de modelo OOP completo são uma muleta (com poucas exceções).

E não há OOP completo em MQL. Até mesmo as muletas estão faltando? Não entendo absolutamente nada.
 
MQL é tudo bom com OOP, e se a herança múltipla for adicionada (pelo menos para interfaces, porque são inúteis em sua forma atual), será perfeito.
 
Ilya Malev:
A MQL está bem com o OOP, se eles adicionarem herança múltipla(pelo menos para interfaces, porque são inúteis em sua forma atual), ela será perfeita.

Portanto, as interfaces são a base do OOP normal, e você está dizendo que tudo está bem na MQL.

 
Alexey Navoykov:

Portanto, as interfaces são a base do OOP normal, e ainda assim você diz que tudo está bem na MQL.

A base do OOP normal é o polimorfismo, não as interfaces. As interfaces são a base de uma certa estrutura de classe. Em geral, eu adoraria falar sobre estes tópicos, mas receio que este fio não seja o lugar para isso.

 
Ilya Malev:

A base do OOP normal é o polimorfismo, não as interfaces. As interfaces são a base de uma certa estrutura de classe. Em geral, eu teria prazer em discutir estes tópicos, mas temo que este ramo não seja adequado para ele.

Estamos discutindo particularidades da linguagem MQL e a ausência de herança múltipla é uma característica bastante característica).

Ok, a base certamente é o polimorfismo, mas sem interfaces separadas não é conveniente em seu uso. Isto muitas vezes leva a passar objetos como argumentos modelo em vez de interfaces.

Descrevi aqui minha variante de simulação de múltiplas interfaces, de modo que uma classe pode ser declarada como

class A : public Interface1<Interface2<Interface3<CBase>>>
{
 ...
};
 
Alexey Navoykov:

Estamos discutindo as peculiaridades da linguagem MQL e a ausência de herança múltipla é uma peculiaridade muito grande).

Ok, a base, claro, é o polimorfismo, mas sem interfaces separadas não é conveniente no uso. Isto muitas vezes leva a passar objetos como argumentos modelo em vez de interfaces.

Descrevi aqui minha variante de imitar múltiplas interfaces. Assim, uma classe pode ser declarada como tal:

Na minha opinião, não é tudo ruim. Não há tantas interfaces principais básicas em C# que seus métodos não pudessem ser reduzidos a uma superclasse básica e depois herdados.

P.S. Implementar algo múltiplo através de construções como <<<<>>>> é um pouco chato. É melhor fazer funções através de operadores, por exemplo, a==b chamadas a.compareto( b ), a[comparador]==b comparador de chamadas.compare(a,b), etc.
12345678910111213...28
Novo comentário
Razão: