Erros, bugs, perguntas - página 2866
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
Tudo é possível, apenas uma macro precisa de ser adicionada
Resultado: 20
Tudo é possível, apenas uma macro precisa de ser adicionada
Resultado: 20.
Isso é muito bom. Não sou bom a adivinhar puzzles.
Desculpe, fiquei confuso enquanto tentava explicar-me))))
Mais uma vez:
Na altura da segunda definição de VALOR, a macro VALOR não está definida, pelo que VALOR é definido como
porque o TMP foi e ainda é definido por VALOR.
Mas o TMP, após a segunda definição de VALOR, é expandido para
(Algo parecido com isto))
O pré-processador apenas preenche o que tem e não importa como e onde é definido. É por isso que tem de ter cuidado com ela. Exemplo:
e agora vamos acrescentar uma coisa má à função, nomeadamente um efeito secundário
E isto é apenas uma inscrição, mas e se o depósito depender desta função?
engraçado) quando o recebe)
acertou, após desfazer a substituição, a primeira linha já não é 10 e a segunda TMP é VALOR, mas não 10. Isto é, a substituição está longe de ser uma tarefa.
engraçado) quando o recebe)
acertou, após desfazer a substituição, a primeira linha já não é 10 e o segundo TMP é um VALOR, mas não 10. Isto é, uma substituição está longe de ser uma tarefa.
Sim. Uma substituição é exactamente uma substituição, um-para-um. Mas quando a macro VALOR é definida no seu código (não confundir com a directiva do pré-processador), o pré-processador expande ainda mais TMP->VALUE->10, e se não, TMP->VALUE. Neste caso, as directivas do pré-processador não estão envolvidas no próprio código, já não estão lá quando compiladas. Exemplo:
Sim. A substituição é exactamente uma substituição, um-para-um. Simplesmente, quando a macro VALOR é definida durante a substituição no seu código (não confundir com as directivas do pré-processador), o pré-processador irá expandir TMP->VALUE->10, e se não, TMP->VALUE. Neste caso, as directivas do pré-processador não estão envolvidas no próprio código, já não estão lá quando compiladas. Exemplo:
Sim, se comentar a segunda substituição VALOR 20, a declaração da variável VALOR desaparecerá e o compilador não a verá e repreenderá)
Tudo é possível, apenas uma macro precisa de ser adicionada
Resultado: 20
Eu desisto))))
Como é definido?
?
Eu desisto))))
Quão certo
?
Tão depressa? Nem todos os especialistas se juntaram ainda... Vamos esperar uma semana.
Dica: isto também funciona (mas a solução é ligeiramente diferente)
Resultado: 20:15
porque o TMP foi, e ainda é, definido por VALOR.
É aqui que entra a refutação "de cima para baixo".
Caso contrário, o TMP não teria sido "como definido, pelo que permanece definido", mas teria sido anteriormente substituído por 10 (ao qual o VALOR é substituído).
Portanto, o pré-processador não está a processar o código linha a linha. O que ainda falta descobrir é como.
@A100, se não se importar, em poucas palavras.
Não é suficientemente interessante para pesquisar e ler no Google, mas o suficiente para perguntar.
O que está errado com a minha lógica?
Imaginei que as cordas são analisadas sequencialmente. Portanto, não há nenhum valor indefinido à direita:
Dica: isto também funciona (mas a solução é ligeiramente diferente)
Tão idêntica em acção à MACRO e MACRO2.
O que está errado com a minha lógica?