Você está perdendo oportunidades de negociação:
- Aplicativos de negociação gratuitos
- 8 000+ sinais para cópia
- Notícias econômicas para análise dos mercados financeiros
Registro
Login
Você concorda com a política do site e com os termos de uso
Se você não tem uma conta, por favor registre-se
Aqui vamos nós.
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:
Será gerado o seguinte pseudo-código
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.
Eis o que vamos fazer.
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).
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.
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.
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
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.