Erros, bugs, perguntas - página 2116
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
Os argumentos da função não são calculados da direita para a esquerda
Resultado da corda (*) : 0:5041
Esperado em ambos os casos: 0:0
Os argumentos da função não são calculados da direita para a esquerda
Resultado da corda (*) : 0:5041
Era esperado em ambos os casos: 0:0
Isto não é um erro. O compilador decide por si próprio em que ordem calcular os argumentos.
Só é preciso tê-lo em conta.
Isto não é um erro. O compilador decide por si próprio em que ordem computar os argumentos.
O erro é o seguinte: até há pouco tempo, a encomenda era estritamente definida por https://www.mql5.com/ru/forum/1111/page2040#comment_5858419(anote a data e o extracto da documentação: garantido). Depois a ordem foi silenciosamente alterada (inclusive na documentação), e poderia ser alterada de forma civilizada - através do inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. Mas como deve o utilizador saber disso? O utilizador deve adivinhá-lo? Ou antes de utilizar qualquer ferramenta, veja a documentação?
Erros de compilação e mais
O erro é o seguinte: até há pouco tempo, a encomenda era estritamente definida por https://www.mql5.com/ru/forum/1111/page2040#comment_5858419(anote a data e extracto da documentação: garantido). Depois a ordem foi silenciosamente alterada (inclusive na documentação), e foi possível alterá-la de uma forma civilizada - através do inline https://www.mql5.com/ru/forum/1111/page2042#comment_5860752. Mas como deve o utilizador saber disso? O utilizador deve adivinhá-lo? Ou consultar a documentação antes de utilizar qualquer ferramenta?
Só não é preciso escrever código que dependa da ordem de cálculo dos argumentos.
Em C++, o compilador tem o direito de inlinear uma função, mesmo que não tenha a palavra-chave inline.
Na MQL não há nenhuma palavra-chave em linha, o compilador integra funções apenas à sua discrição.
A ordem dos cálculos da direita para a esquerda foi aparentemente devido ao facto de os argumentos desta ordem serem colocados na pilha,
mas também podem ser passados através de registos.
E para funções incorporadas, não há nenhuma passagem de argumentos como tal.
1. Só não precisa de escrever um código que depende da ordem em que os argumentos são calculados.
2. Em C++, o compilador tem o direito de inline uma função, mesmo que não tenha a palavra-chave inline.
3. Na MQL não existe uma palavra-chave em linha, o compilador apenas incorpora funções à sua própria discrição.
4. A ordem dos cálculos da direita para a esquerda parece estar ligada ao facto de que os argumentos são colocados na pilha nesta ordem,
mas também podem ser passados através de registos.
5. E não há qualquer argumento que passe por funções incorporadas.
1. Porque não deveria ser assim se a ordem inversa é garantida na documentação e o código é mais simples e claro neste caso? Mais vale negar a utilização de 5 + (2*3) prioridades operacionais e exigir que os parênteses (5 + (2*3)) sejam colocados em todo o lado - no caso de ser subitamente alterado
2. O compilador C++ impõe certos requisitos às funções incorporadas, o que exclui tal situação https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.
3. foi assim que foi proposta a sua introdução
4. Nos registos (ao contrário da pilha), os argumentos podem ser colocados em qualquer ordem, incluindo a ordem inversa
5. Não é a ordem de passagem que importa - é a ordem dos argumentos de cálculo, e esta é a ordem de qualquer função com mais do que um argumento. E C++ leva-o em conta antes de fazer (ou não fazer) uma função em linha (ver item 2)
1. Porque não, se a ordem inversa é garantida na documentação e o código é mais simples e claro. Mais vale negar usar 5 + (2*3 ) e exigir a colocação de parênteses (5 + (2*3)) em todo o lado - no caso de ser subitamente alterado
2. O compilador C++ impõe certos requisitos às funções incorporadas, o que exclui tal situação https://www.mql5.com/ru/forum/1111/page2136#comment_6454818.
3. foi assim que foi proposta a sua introdução
4. Nos registos (ao contrário da pilha), os argumentos podem ser colocados em qualquer ordem, incluindo a ordem inversa
5. Não é a ordem de passagem que importa - é a ordem dos argumentos de cálculo, e esta é a ordem de qualquer função com mais do que um argumento. E C++ leva-o em conta antes de fazer (ou não fazer) uma função em linha (ver ponto 2)
3. não sei o que isso lhe dá. Quer proibir o compilador de incorporar funções sem especificar explicitamente em linha?
2. Não sei a que se refere.
4. Estava apenas a sugerir a que é que essa encomenda e o seu cancelamento estavam relacionados. Não creio que tenha sido feito por acidente e será sempre assim a partir de agora. Não há nada de terrível nisso.
5. Está enganado. Em C++, a ordem dos argumentos de cálculo não está definida.
1. Escrevo em C++ há muitos anos e nunca descobri que isto fosse um problema.
3. não sei o que isto fará por si. Quer evitar que o compilador incorpore funções sem especificar explicitamente em linha?
4. Limitei-me a sugerir a que é que a encomenda e o seu cancelamento estavam relacionados. Não creio que tenha sido feito por acidente e será sempre assim agora. Não há nada de terrível nisso.
5. Está enganado. Em C++, a ordem dos argumentos de cálculo é indefinida.
3. eu estava a sugerir que o compilador não deveria ser autorizado a alterar a ordem dos argumentos de cálculo para as funções sem linhas de entrada.
5. A ordem de cálculo é definida pela implementação (o compilador) e é bastante concreta (ou da direita para a esquerda ou da esquerda para a direita), e aqui, por exemplo:
não é claro que ordem é 2-1-3 ou 2-3-1 ou o que quer que seja.
Resultado: 5041:0:5041.
Esperado: 0:0:5041 da esquerda para a direita ou
5041:0:0 da direita para a esquerda
não é claro qual é a ordem 2-1-3 ou 2-3-1 ou o que quer que seja
Não compreendo porquê escrever um código obviamente ambíguo?
Não compreendo porquê escrever um código obviamente ambíguo?
Uma pergunta semelhante para si https://www.mql5.com/ru/forum/1111/page2037#comment_5842347