Erros, bugs, perguntas - página 1017
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
Em suma, não pode definir uma implementação de função em .mqh e utilizá-la sem problemas em qualquer .ex5
:)
Mas quando se usa um .ex5 para chamar funções noutro .ex5, mesmo que a função com esse nome exista em ambos, é necessário certificar-se de especificar o espaço de nomes com precisão. Ou seja, o ::In() deveria, em teoria, resolver o problema. E se não o fizer - este é um bug que precisa de ser corrigido.
Vamos parar com a resposta do ServiceDesk:
"Ao compilar 1.mq5, dentro da função B() não está claro que função deve ser chamada,
importada A() ou exportada A() - porque o compilador não compreende que se referia à mesma função"
Têm razão na forma - mas se o desejar, o compilador pode (e deve) ser informado de que é a mesma função, pois repito o nome do módulo no momento da compilação - está disponível (especificado em #import).
Tanto mais que, se primeiro colocar :: num lugar e compilar, depois apagar e colocar :: noutro - tudo funciona, mas tem de concordar - é muito inconveniente e depois de 10-15 tais permutações forçadas mudei para #define
Vamos parar com a resposta do ServiceDesk:
"Ao compilar 1.mq5, dentro da função B() não é claro qual a função que deve ser chamada,
A() importado ou exportado A() - uma vez que o compilador não entendeu que se referia à mesma função".
Estão correctas na forma - mas o compilador poderia (e deveria) ser informado de que é a mesma função se desejado, pois repito que o nome do módulo está disponível no momento da compilação (especificado em #import).
Para tais dicas existe um operador de resolução de contexto "::", mas não é aplicável neste caso porque o nome do módulo (ficheiro) é também o mesmo.
O conselho é adequado - alterar a estrutura do programa.
Mais ainda, se primeiro colocar :: e compilar num lugar e depois remover e colocar :: num outro - tudo funciona, mas tem de concordar - é muito inconveniente
e depois de 10-15 tais permutações forçadas mudei para #define
As definições parametrizadas só são úteis quando a detecção do tipo é indesejável ou quando os parâmetros são substituídos por pedaços "verbosos" de texto. Como substituto de uma função em linha, uma definição é sem dúvida prejudicial para a saúde de um programa.
--
No vosso caso eu recusaria a utilização de bibliotecas .ex5, e tudo funcionaria muito bem. A única utilização prática delas é na implementação escondida (ao vender), e não vejo a sua utilização em outros casos.
Está a escrever para venda?
Está a escrever para venda?
Para mim.
Não o posso fazer sem .ex5. Também tenho funções como F( string& [] ), de alguma forma não cabem em .dll :)
Talvez se possa empurrá-los através de um separador, mas ainda não o experimentei
A MQL5 não tem apenas funções em linha (na forma) e eu utilizo macros paramétricas, o que não é totalmente correcto, porque não há controlo de tipo.
Além disso, o compilador não optimiza as expressões, pelo que há uma penalização adicional de velocidade. É melhor verificar.
A propósito, sobre o inlining - funciona. Tive alguns problemas com o debugger por causa disso.
A propósito, sobre o revestimento -- funciona. Também houve problemas com o depurador por causa disso.
Por isso, funciona a nível de compilador. E gostaria que funcionasse a nível linguístico. Dei um exemplo acima - tudo funciona através do inexplicável "contornar o compilador", enquanto o trabalho directo requer passos extra, por vezes significativos, porque como sugeriu não incluir a descrição e implementação de uma mesma função num único ficheiro é certamente possível, mas depois 10 .mqh completos são decompostos em 100 .mqh mais pequenos
Ainda não tenho andado atrás da velocidade. O principal é a conveniência e que a quantidade de código não cresça exponencialmente.
Até já enfrentei a necessidade de usar analógicos #if #else em MQL5 (até agora é um pouco complicado, mas funciona aqui e ali)
Ainda não estou à procura de velocidade. O principal é a conveniência e que o volume do código não cresça exponencialmente.
A100:
Não funciona sem .ex5. Também tenho funções como F( string& [] ), mas elas não cabem em .dll de alguma forma :)
....
Caramba... :)
Não sugeri o uso de DLL em vez de bibliotecas .ex5. Apenas lotes e muitos .mqh e um executável .mq5, nada mais.
Apenas lotes e lotes de .mqh e um executável .mq5, nada mais.