Erros, bugs, perguntas - página 493
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
Eu não discuto.
mas desta forma
há um arredondamento de qualquer maneira, deveria fazer isso?
Desenvolvedores.
Acidentalmente fiz o processamento de carraças em Expert Advisor, após o que apareceu um erro crítico sobre o transbordamento da pilha.
O problema é que não há informação específica na mensagem sobre o que e onde exactamente aconteceu.
Sugiro que se esclareça o texto desta mensagem, se possível quer apanhar tais problemas (como chamar um método de classe a partir de um método chamado) na fase de compilação.
A razão pela qual iCustom() atribui valores arbitrários a essas células tampão, que na realidade não foram preenchidas com nada, não me é clara, assim como a razão pela qual não pode ser evitada de forma alguma.
Suponho que tenha algo a ver com a atribuição de memória para a matriz correspondente de dados de indicadores buffer.
Tal operação de iCustom(), quando é impossível determinar a origem e a verdade dos dados, parece-me inadmissível e cria riscos adicionais para o utilizador.
Se iCustom() atribuir valores arbitrários, inconsistentes com os valores reais às células tampão de qualquer forma,
porque não atribui valores iguais a Empty_Value a estas células tal como é implementado no MT4?
Então, pelo menos o seu estatuto seria claro.
Desenvolvedores.
........... se possível quer apanhar problemas como este (como chamar um método de classe a partir de um método chamado) em tempo de compilação.
Sou contra. Tornaria o compilador excessivamente complicado e, portanto, menos fiável.
Cabe ao programador rastrear a recorrência incorrecta.
Mas eu gostaria que a mensagem de erro contivesse o nome da função que transbordou a pilha.
Ninguém a não ser o autor pode decidir com que valores tampão não utilizados devem ser preenchidos. Você diz Vazio_Valor, mas eu, por exemplo, quero que seja 0, ou outra coisa qualquer. Seja qual for o valor pretendido, inicialize-o com ele.
Isto é correcto e lógico. Mas o problema é que as células tampão que o utilizador não preencheu com nada (!), a função iCustom() preenche periodicamente com lixo arbitrário à sua discrição. É suposto ser assim?
Sou contra. Tornaria o compilador exorbitantemente complexo e, portanto, menos fiável.
Cabe ao programador rastrear a recorrência incorrecta.
Mas eu gostaria que a mensagem de erro contivesse o nome da função que transbordou a pilha.
Sim, não complicamos propositadamente o motor de trabalho (afinal é nativo 32/64) com meta-informação.
A recuperação é geralmente fácil de apanhar - depende directamente do tamanho das variáveis locais, e há muito poucos lugares assim num programa.
Isto é correcto e lógico. Mas o problema é que as células tampão, que o utilizador não preencheu (!), a função iCustom() preenche à sua discrição com lixo aleatório. É suposto ser assim?
Se o indicador personalizado não preencher correctamente o seu tampão, este indicador personalizado é culpado.
E se este indicador personalizado envia os seus resultados através do iCustom, é duplamente culpado, uma vez que engana os utilizadores.
Se um indicador personalizado não preencher correctamente o seu tampão, isso significa que este indicador personalizado é culpado.
E se este indicador personalizado der os seus resultados através do iCustom, ele é duplamente culpado, pois engana os utilizadores.
Se um indicador personalizado não preencher correctamente o seu tampão, a culpa é deste indicador personalizado.
E se este indicador personalizado produzir os seus resultados através do iCustom, ele é duplamente culpado, porque engana os utilizadores.
Ainda não compreendo, o que o impede de tornar o programa não só eficiente, mas também conveniente? Se bem me lembro, o raciocínio para a ausência de inicialização integrada de amortecedores indicadores em 5 é para optimizar a velocidade. Neste caso, o desenvolvedor do indicador tem de codificar sozinho as próprias cordas de inicialização ("zeros"), que anteriormente em quatros era executado pelo núcleo. Portanto, a eficiência resultante não parece melhorar, e a usabilidade sofre. Mas como foi decidido fazê-lo desta forma por alguma razão, porque não torná-lo opcional? Ou seja, poderíamos introduzir mais um #propriedade, especificando se os amortecedores devem ser inicializados automaticamente ou não.
Para resumir, vou repetir a ideia que já exprimi uma vez: a tarefa da plataforma, que é MT, é proteger o utilizador (o programador) de possíveis armadilhas, tanto quanto possível.
Isto é correcto e lógico. Mas o problema é que as células tampão que o utilizador não preencheu (!) com nada, iCustom() preenche periodicamente com lixo arbitrário à sua própria discrição. É suposto ser assim?
Na verdade, é uma regra comum: inicializar arrays está ao critério do utilizador. Uma matriz não inicializada contém valores aleatórios da memória atribuída a ela. O utilizador pode ter uma boa razão para não inicializar a matriz desnecessariamente (por exemplo, para poupar tempo). Por vezes poupo tempo desta forma quando tenho a certeza de que não terei de ler e "comer" esse lixo antes que a verdadeira informação esteja lá.
Não vejo qualquer malícia do lado da MQ. Preferia opor-me se eles "profilacticamente" começassem a abrandar os meus programas.