Erros, bugs, perguntas - página 2890
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
Se precisar de apanhar um erro deste valor, rubrice-o bem com 333 ))
É apenas um valor inicial.
É isso mesmo, é um insecto. Assim, ou damos um aviso sobre a atribuição de variáveis não inicializadas em todos os casos, ou não o fazemos, e inicializamo-lo com zero por defeito, por exemplo, dentro da língua em todos os mesmos casos.
É isso mesmo, é um insecto. Acontece que ou damos um aviso para atribuir variáveis não iniciadas em todos os casos, ou então não o damos, mas iniciamo-lo com zero por defeito, por exemplo, dentro da língua em todos os mesmos casos.
Só nos exemplos acima é que viu tais casos?
Só nos exemplos acima é que viu tais casos?
Fórum sobre comércio, sistemas de comércio automatizados e testes estratégicos
Insectos, insectos, perguntas
A100, 2020.10.27 16:11
É preciso inicializá-lo, mas apenas com um valor significativo. Não existe tal valor no exemplo acima, pelo que a prática não é má, a única possível. Caso contrário, haveria dupla inicialização
E onde está aatribuição de variáveis não inicializadas? Que variável não é inicializada? e a quem está a ser atribuída? O que destacou: j de = para a esquerda j=, não para a direita =j, ou seja, não é atribuído a ninguém antes de lhe ser atribuído um valor
Só nos exemplos acima é que viu tais casos?
Sim, esqueci-me, em todos os casos a variável não-inicializada tem uma atribuição, não o contrário. Talvez o compilador vá de cima para baixo numa fila, caso em que sim, a tarefa está em baixo e vice versa em cima. Há também um aviso sobre uma possível atribuição a uma variável não-inicializada.
E onde está aatribuição de variáveis não inicializadas? Que variável não é inicializada? E a quem está a ser atribuída? O que destacou é j=, não =j
Atribuição a uma variável não-inicializada, no corpo do laço. Antes da primeira iteração j ainda não foi inicializada.
Será inicializada após a primeira iteração passar.
O corpo do laço é executado primeiro, e depois o escopo incremental. Que substituiu por i = j
Atribuição a uma variável não-inicializada, no corpo da função. Antes da primeira iteração j ainda não foi inicializada.
Será inicializada após a primeira iteração.
O corpo da função é executado primeiro, e depois a área de incremento. Que substituiu por i = j
Não, isso mesmo, não inferir j na primeira iteração é iniciado apenas j=f(i) e na segunda será apenas i=j Penso que o compilador está a analisar de cima para baixo e a dar avisos.
Não, isso mesmo, a variável j não é inicializada na primeira iteração apenas j=f(i) e na segunda iteração apenas i=j Penso que o compilador analisa de cima para baixo e dá avisos.
Sim, mas antes da primeira iteração a variável j ainda não foi inicializada, é isto que o compilador está a jurar.
Sim, isso foi errado, em todos os casos de variável não-inicializada há uma atribuição, não o contrário. Talvez o compilador vá de cima para baixo, por isso sim, a tarefa está em baixo e vice versa em cima. Há também um aviso sobre uma possível atribuição a uma variável não-inicializada.
Isto pode acontecer quando o compilador não tem informações objectivamente:
isto é, talvez f() estivesse a inicializar i e talvez não. E aqui o compilador C++ dá um aviso, enquanto que o MQL não o faz de alguma forma.
Isto pode ser quando o compilador não tem objectivamente nenhuma informação:
isto é, talvez f() tivesse sido inicializado, talvez não. E aqui o compilador C++ dá um aviso, o MQL não.
Não posso saber o que dizem. Penso que um compilador mais simples. Analisa a sintaxe do layout de cima para baixo para erros de sintaxe óbvios, não respeitando tipos e utilizando variáveis erradas. Quando no segundo exemplo a inicialização foi colocada, não gerou um aviso. Embora a execução do programa seja idêntica.