Erros, bugs, perguntas - página 1692
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
Duas fontes com o mesmo conteúdo ocupam um número diferente de bytes (duas vezes mais diferente).
Parece que a dada altura há algum mexerico unicode.
Em geral, como posso fazer um ficheiro grande para ocupar metade do número de bytes? Ao mesmo tempo, para que o texto da fonte permaneça inalterado.
Duas fontes com o mesmo conteúdo tomam um número diferente de bytes (duas vezes mais diferente).
Parece haver aí, a dada altura, algum mexer em unicode.
Em geral, como é que faço um ficheiro grande para ocupar metade do número de bytes? Ao mesmo tempo, para que o texto fonte permaneça inalterado.
Copiei o conteúdo do ficheiro grande para o Bloco de Notas e guardei-o num novo ficheiro. Tornou-se metade do tamanho.
E como fazer metaeditor para não criar "grosso"?
E como fazer com que o metaeditor não crie os "gordos"?
Tê-lo-ia executado primeiro. O erro é SOMENTE aquiAindaAll chama antes que isso aconteça sem problemas.
Este é realmente esquisito. Os prós aqui estão errados nas três chamadas.
É uma história diferente.
Não, é a mesma coisa. Já analisei as chamadas de método no depurador: comentei a última chamada no vosso exemplo, coloquei pontos de ruptura em ambos os métodos da classe e comecei a depuração. O ponto de quebra foi removido do método func(const int&), ou seja, o compilador expulsou este método, pelo que a ambiguidade foi eliminada. E se chamar uma função com um argumento constante, o compilador evidentemente não remove o método com a referência e o resultado é uma sobrecarga insolúvel... Algo parecido com isto. Em qualquer caso, o seu código é falho em C++.
Sergei Vladimirov:
Em qualquer caso, o seu código é falho em C++.
Em mql, há recheio adicional com referências. Seja como for, não gosto do comportamento do código acima.
Este é realmente esquisito. Há aqui um erro nos prós e contras das três chamadas.
Em mql há engenhocas de ligação extra. De qualquer modo, não gosto do comportamento do código acima.
Neste caso, eu não gostaria que houvesse qualquer mudança no sentido de C++.
Agora, esta é a questão do coro do debate. Acabei de lhe dizer "onde está o cão no buraco".
O comportamento, a propósito, é o mesmo que em C++, mas se deixar apenas as duas primeiras chamadas, o compilador deita fora uma das funções, de modo que a incerteza desaparece. Mas continua a ser um erro, apenas corrigido automaticamente pelo compilador.
O erro está correcto aqui.
Mas é uma questão discutível. :) Eu apenas lhe respondi "onde o cão está escondido".
Não há realmente lá nenhum cão. A prioridade em sobrecarga pode ser definida no compilador, como os programadores fizeram com as duas primeiras chamadas.