Características da linguagem mql5, subtilezas e técnicas - página 202
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
As funções padrão recebem os argumentos da esquerda para a direita.
As funções personalizadas recebem os argumentos da direita para a esquerda.
Resultado.
Será assim que deve ser?
É assim que deve ser?
Esta é uma UB em que não se pode confiar. Isto é, deve-se evitar explicitamente situações em que a lógica de um programa depende da ordem em que os argumentos são avaliados
As funções regulares recebem argumentos da esquerda para a direita.
Aqui está um exemplo de refutação:
Resultado: 2 1
Esta é uma UB em que não se pode confiar. Isto é, devemos evitar explicitamente situações em que a lógica de um programa depende da ordem em que os argumentos são avaliados
Eis um exemplo a refutar:
Acontece que tudo é instável com os personalizados. Com os personalizados, tudo é instável desde o início.
Acontece que tudo é instável com os normais. Com os personalizados, é inequívoco desde o início.
A diferença é que existem funções regulares (da direita para a esquerda) e funções em linha (ordem indefinida).
funções em linha não são funções de todo, ou seja, não podem ter um endereço. Deste ponto de vista, não há diferença entre funções regulares e funções personalizadas, por exemplo, não é claro porque é que os argumentos da função personalizada mais simples (que é na sua essência em linha) são sempre calculados da direita para a esquerda. Não excluo que no futuro, para funções em linha, a ordem possa mudar, por isso
Sugeri de uma vez a introdução de uma palavra-chave em linha para uma utilização segura da ordem dos cálculos:
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Erros, bugs, perguntas
A100, 2017.10.05 14:30
Isto demonstra mais uma vez a utilidade da palavra-chave em linha C++ (havia aqui uma opinião de que era supostamente obsoleta).
Entre outras coisas, inline significa de facto que o programador não utiliza a ordem de cálculo dos parâmetros da função e se o compilador decidir tornar a função inline inline, então o compilador pode utilizar a ordem de cálculo avançada como mais eficiente (a ordem inversa de cálculo é obviamente eficiente apenas para as funções chamadas).
Ao mesmo tempo, se o compilador decidir incorporar uma função não em linha, deve usar a ordem inversa (geral) de avaliação, mesmo que isso leve a uma perda de eficiência (porque o programador assumiu esta ordem sem ter declarado a função em linha)
inline também seria apropriado em MQL, onde a ordem de computação não pode ser controlada explicitamente
A diferença é que existem funções normais (da direita para a esquerda) e funções em linha (ordem indefinida).
As funções em linha não são funções de todo, ou seja, não podem ter um endereço. Deste ponto de vista, não há diferença entre funções regulares e funções personalizadas, por exemplo, não é claro porque é que os argumentos da função personalizada mais simples (que é na sua essência em linha) são sempre calculados da direita para a esquerda. Não excluo que no futuro, para funções em linha, a ordem possa mudar, por isso
Sugeri de uma vez a introdução de uma palavra-chave em linha para a utilização segura da ordem de cálculo:
Obrigado pelos esclarecimentos, não tinha pensado em inline.
Uma tal opção não afecta o resultado.
Obrigado pelo esclarecimento, não tinha pensado no inline.
Esta opção não afecta o resultado.
Não tem efeito agora, porque não existe na MQL
e no futuro pode ter um significado real, caso contrário porque é que seria introduzido?
Não tem efeito agora, porque na MQL está um pouco ausente agora
e no futuro pode ter um significado real, caso contrário porque teria sido introduzido?
Tanto quanto me lembro da ajuda à versão, ela foi introduzida como um stub para permitir a entrada de ficheiros *.h em linha.