Erros, bugs, perguntas - página 1016
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
Sim, obrigado, cometi um erro ao simplificar o código fonte - agora reescrevi o erro de forma diferente
Apaguei o anterior para evitar confusão.É terrível. É mesmo. Que coisa terrível de se viver...
--
Ouça, o que tem para si? Se não for segredo.
Escreve o seu conselheiro em Lisp? Tiro-lhe o chapéu, mas sugiro que mude para Haskell.
;-)
Ouve, para que precisas dele? Se não é segredo.
A MQL5 não tem funções em linha (na forma) e eu uso macros paramétricas.
Sim, eu também os utilizo, mas não tão assustadoramente aninhado. ))))
Para sua referência, o mql5 traduz todas as pequenas funções para substituição em linha. Por outras palavras, podemos assumir que a palavra-chave "em linha" está em todas as funções definidas pelo utilizador por defeito.
A decisão de substituir uma macro ou compilar numa função é, em última análise, tomada pelo compilador (tal como C++, a propósito). Portanto, não vale a pena tentar acelerar as coisas dessa forma, todas as funções simples são de qualquer forma simplificadas.
// E a propósito - com controlo de tipo! :)
Para referência, o mql5 traduz todas as pequenas funções em substituições em linha. Por outras palavras - pode assumir que a palavra-chave "em linha" está em todas as funções do utilizador, por defeito.
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
Lá B() em 1.mqh é suposto estar em linha - mas todos juntos - não se compila normalmente - apenas separadamente. ServiceDesk referindo-se à ambiguidade da chamada não aprofundou a essência do problema e recomendou a organização do projecto de uma forma diferente. Como poderia ser feito de forma diferente? Tudo funciona apenas quando removo a implementação B() de .mqh para .ex5. E o que é então a forma em linha?
A propósito, na MQL4, esse exemplo funciona - sem erros, embora B() não esteja de facto em linha, mas na forma - em linha.
E não o fiz por rapidez, fi-lo por conveniência. Em essência, podem estar em linha, mas não na forma(!).
E quanto à forma.
"Quem é um Studebaker? É o seu parente Studebaker? O teu papá é um Studebaker?"
As dificuldades surgem se definir inline em .mqh e depois utilizá-lo em vários .ex5.
Não há dificuldades. Se não cometer erros lógicos e não compreender correctamente como funciona um compilador.
Vou tentar encontrar o link agora
https://www.mql5.com/ru/forum/1111/page1013#comment_520221
A função B() aqui está essencialmente em linha
Não consegui eliminar erros como "chamada ambígua para função sobrecarregada com os mesmos parâmetros" - eles não ocorreram a menos que se coloque num .ex5 separado
O compilador franziu-lhe o sobrolho de uma forma simpática, mesmo com base nos méritos. Está a tentar ligar ao inluder uma libu, que define o mesmo inluder em que se está a compilar. Então o que é que quer? Se fosse um compilador, o que faria?
Isto pode ser notícia para si, mas uma função em linha escrita numa DLL não pode de forma alguma ser usada como macro fora desta DLL. // Em tempo de execução o código fonte já não existe
Acho que a segunda notícia para si: todas as libras em mql(4, 5) estão dinamicamente ligadas. Isto é essencialmente DLL's.
Resumindo: estava de facto a tentar referir-se a si próprio, referindo-se a si próprio, referindo-se a si próprio...... etc.
Concordar, seria muito pior se tudo fosse compilado sem objecções, e depois, no tempo de execução, a libra tentasse carregar-se a si própria recursivamente até ficar sem memória.... :))
?
É por isso que existe a palavra-chave em linha em C/C++
Não é de todo essa a razão. Tenho a certeza que o exemplo na ligação não será compilado em C++.
// Sou demasiado preguiçoso para verificar. Simplesmente não faz sentido. Se eu não entender como construir código fonte recursivamente organizado, o compilador também não o entenderá.
A propósito, esse exemplo funciona em MQL4 - sem erros, embora B() não esteja em linha, mas na forma - em linha
Não o faço. Embora... uma vez que não há ali nenhuma sobrecarga de funções, talvez o compilador não tente insinuar uma sobrecarga errada - simplesmente ignora estupidamente as definições repetidas.
Compila em MQL4 (!) e em C/C++ se escrever em linha antes de B()
Não há aí qualquer recorrência, de facto há
int A( int ) e #define B() A( 0 )
É muito simples lá - se não for muito preguiçoso - dê uma olhada na sua cabeça fresca - apenas declaração separada e implementação de funções :)
Aí B() em 1.mqh é suposto estar em linha - mas todos juntos não estão a compilar normalmente - apenas separadamente. ServiceDesk referindo-se à ambiguidade da chamada não foi ao fundo do coração do problema e recomendou organizar o projecto de outra forma. E de que outra forma?
Só funciona se remover a implementação B() de .mqh em .ex5. O que é então a forma em linha?
Acabou de responder à sua própria pergunta:
O problema não é de modo algum a inineidade do B(), mas sim a sua redefinição.
É que C/C+++ compreende (usando a palavra-chave inline) que isto não é uma redefinição, e MQL5 não, embora possa distinguir pelo nome do módulo compilado e um especificado em #import. Não sei como é que a MQL4 o entende.
Em suma, não se pode definir uma implementação de uma função em .mqh e utilizá-la sem qualquer problema em qualquer .ex5.
Exactamente correcto - é que C/C+++ compreende que isto não é uma redefinição, e a MQL5 não o faz.
C/C++ são capazes de compreender isto APENAS quando compilam uma libra estática, porque a informação do nome da fonte é armazenada no ficheiro objecto (apenas para reconhecer a recompilação).
Com bibliotecas dinamicamente ligadas, isto não funcionará e se funcionar não será devido à detecção de reimplementação mas sim devido a "regras de prioridade" para a congruência de nomes da fonte actual e DLL. Algumas línguas têm tais regras (Delphi em particular, provavelmente alguns compiladores C/C++ também as têm).