OOP, modelos e macros em mql5, sutilezas e usos - página 5
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
Sobre o multi-passing - apressado, ingenuamente pensava que o mcl o permitiria
Ну вот я с этого и начинал разговор тут. Планировал тоже заменять все статики на глобалы (хоть это и жесть конечно). Но как показано выше, с шаблонами такое не прокатит. С макросами тоже. А я всё это широко применяю. Поэтому и сделал свою реализацию. Хотя она конечно не решает всех проблем. Динамические массивы по-прежнему нельзя инициализировать, константные типы тоже. Поэтому их однозначно придётся выносить на глобальный уровень
Também utilizo amplamente modelos e macros, mas considero as funções livres apenas como elementos arquitetônicos auxiliares (e geralmente indesejáveis). Quando todas as implementações são embaladas dentro de objetos e as estáticas são declaradas apenas em nível de classe, bugs irritantes aparecem, exceto que às vezes é difícil entender a lógica de sua seqüência correta de declarações, para que o compilador não jure...
Portanto, há variáveis aqui. E com funções, sim, é multi-passível, então tudo estava certo. O problema surge justamente por causa da ordem de inicialização das funções. Em suma, em C++ há uma ordem rigorosa que se aplica às variáveis, funções e tipos. E em MQL tudo é diferente.
Os passes múltiplos são ruins em qualquer caso - você pode encontrar recursões, bloqueios, etc. Mas, pelo lado positivo, isso pode ser feito. Portanto, apenas com sabedoria, cautela (ou seja, declaração para frente), e não como agora com compilador multi-pass - como se para qualquer função fosse feita declaração para frente, mais cedo ou mais tarde este ancinho vai atingir sua testa.
A passagem múltipla é ruim em qualquer caso - você pode se deparar com recorrência, impasse, etc. Mas é possível fazer uma declaração prévia no lado positivo. Portanto, apenas com sabedoria, cuidado e não como agora com o compilador multipasse - como se para qualquer função fosse feita uma declaração de avanço, mais cedo ou mais tarde este ancinho vai atingir sua testa.
Eu concordo. Este tópico foi discutido um pouco antes. É o que muitos aqui gostam na linguagem - que você não se preocupe com a ordem da declaração de funções. Escusado será dizer que eu mesmo fiquei feliz com isso há algum tempo). Mas sua tédio me irritou no lado positivo. Mas com a experiência vem a compreensão.
Também utilizo amplamente modelos e macros, mas considero as funções livres apenas como elementos arquitetônicos auxiliares (e geralmente indesejáveis). Quando todas as implementações são embaladas dentro de objetos e as estáticas são declaradas apenas em nível de classe, bugs irritantes aparecem, exceto que às vezes é difícil entender a lógica de sua seqüência correta, para que o compilador não jure...
Concordo, se tudo estiver claramente alinhado no OOP, então não só as funções livres não são necessárias, mas também os métodos modelo.
Os métodos modelo são necessários onde você não quer escrever um monte de código repetitivo, seja OOP ou não OOP. As funções livres são outra questão - estes são estilos de programação diferentes.
Os métodos modelo são necessários onde você não quer escrever um monte de código repetitivo, seja OOP ou não OODOP
No OOP, foram inventadas interfaces para este fim.
As interfaces são um pouco diferentes. Se eu quiser que o mesmo código faça o mesmo trabalho com tipos diferentes dependendo da classe do parâmetro (sem declarar classes adicionais), as interfaces não vão ajudar.
As interfaces são um pouco diferentes. Se eu quiser que o mesmo código faça o mesmo trabalho com tipos diferentes dependendo da classe do parâmetro (sem declarar classes adicionais), a interface não vai ajudar.
Se os parâmetros são de tipos diferentes, então faz sentido fazer vários métodos sobrecarregados com tipos correspondentes. Você ainda terá que separá-los de alguma forma na função. Então é melhor dividi-los em funções separadas, do que criar uma bagunça que também toma um tipo impessoal, ou seja, por engano você pode passar qualquer coisa para dentro dela e obter um erro de compilação dentro da biblioteca, o que não é bom. E talvez até não, o que é duplamente ruim).
Em resumo, as funções de modelo OOP completo são uma muleta (com poucas exceções)
Em resumo, as funções de modelo são uma muleta em pleno OOP.
Portanto, aqui estamos nós.
Fórum sobre comércio, sistemas automatizados de comércio e teste de estratégias comerciais
Características da linguagem mql5, dicas e truques
Alexey Navoykov, 2019.01.25 10:11
Bem, foi assim que comecei a conversa aqui. Eu estava planejando substituir todas as estáticas por globais também (embora seja uma coisa cruel, é claro). Mas como mostrado acima, não vai funcionar com modelos e macros também. E eu os uso todos amplamente. É por isso que fiz minha própria implementação. Embora não resolva todos os problemas. As matrizes dinâmicas ainda não podem ser inicializadas, nem os tipos constantes. É por isso que definitivamente terão que ser globalizadas.