MQL5 O compilador não faz distinção entre uma classe e um ponteiro para ela - página 6
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
Fundir implicitamente este ponteiro em um objeto
O nome correto é "Implicit pointer dereferencing".
Eu apoio a proposta de não permitir, deixar implícito o desreferenciamento apenas quando se refere a um membro da classe, como por exemplo:
Aqui é o oposto - um ponteiro é implicitamente fundido a um objeto (desreferenciado) e então operador= é aplicado a ele. fxsaber também o mencionou ontem.
Embora logicamente não contradiga as regras de MQL (já que chamar operador= é igual a chamar qualquer outro método de objeto), leva a ambigüidade na compreensão de tal código e a erros difíceis de encontrar. E isto diz respeito não somente ao operador= mas == e != também, pelo menos. Talvez tal fundição deva ser proibida também para outros operadores, pois em C++ você pode aplicar aos operadores: +-<>[].
A breve conclusão é a seguinte: ao aplicar a um ponteiro operadores que são permitidos para apontadores em C++, proibir uma fundição implícita deste ponteiro a um objeto. Correspondentemente, o exemplo acima teria um erro de compilação.
Sim, estou vendo. Ao utilizar estes exemplos simples, quis mostrar a todos os céticos que o ponteiro e o objeto são entidades diferentes e não se deve confundi-los.
E esta circunstância requer pelo menos um certo estilo de escrita de código para que você não cometa um erro e construa um código que compila e até mesmo passe no teste, mas reprove em condições reais, pior ainda se tiver sido escrito para venda. Não será uma tarefa fácil encontrar um ponto de erro no código onde tudo está tão "implícito".
Encontrar um lugar de erro em código onde tudo está tão "implícito" será um desafio e tanto.
Seria melhor se os desenvolvedores deixassem as coisas como estão. Se eles começarem a mudá-lo novamente agora, a linguagem, um monte de programas pararem de compilar, ou pior, pararem de funcionar como esperado, haverá um tumulto mundial.
Do meu ponto de vista, os auto-objetos em µl são um rudimento, sub-pontos com funções limitadas (ponteiro constante com auto-eleição), e na maioria das vezes não precisam ser usados (exceto para o coletor de lixo).
Seria melhor se os desenvolvedores deixassem as coisas como estão. Se eles começarem a mudar novamente agora, a linguagem, um monte de programas pararem de compilar, ou pior, pararem de funcionar como esperado, haverá um tumulto mundial.
As mudanças aqui são mínimas. É apenas uma questão de acrescentar regras de compilação a
para que não permita compilar a porcaria que agora é considerada boa.
Para que não deixe você compilar o tipo de heresia que agora é considerada boa.
como A a = novo A? Ou o que exatamente ) é agora usado por todos, portanto não tem efeito algum
Mas se você escreve A a, *b = a; você recebe um erro de tempo de execução, neste caso o compilador deve gerar explicitamente o aviso "provável uso da variável não inicializada 'b'" como faz com todos os outros tipos. Se não houver nenhum erro de compilação. Mas não por causa da tarefa em si, mas por usar uma função sobrecarregada em uma variável não inicializada que causa um erro de tempo de execução, é claro. Isto é realmente um bug e parece estar relacionado à otimização excessiva do código.
E, em geral, não há heresia em atribuir o automóvel ao dino e vice-versa, estas podem ser características úteis.
Mas eu cancelaria tal coisa como a cópia implícita de objetos ao mesmo tempo. Embora seja um padrão em C++. Na verdade, é a razão de todos esses problemas.como A = novo A? Ou o que exatamente )
Bem, isso é desnecessário dizer. Há aqui um vazamento de memória.
Mas, em geral, não há heresia em atribuir o automóvel ao dino e vice-versa, estas podem ser características úteis.
Que assim seja. Mas explícito. E isso não será feito por meu erro, mas porque tenho que fazê-lo.
Bem, isso é um dado adquirido. Há aqui um vazamento de memória.
Bem, este vazamento é puramente culpa sua. Se você tem um objeto à esquerda, por que você escreveria tal construção?
Mas a situação inversa, quando você atribui algo a um ponteiro e este é subitamente desreferenciado, é um erro não óbvio.
Aqui tudo está misturado, tanto moscas como costeletas. Estou falando sobre a discussão do tema.
Se você tem um objeto à esquerda, por que escrever uma construção assim?
O fator humano! O compilador deve mantê-lo a um nível mínimo.
O fator humano! O compilador deve mantê-lo a um nível mínimo.