Como é que passo por uma enumeração de forma consistente? - página 3
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
Os exemplos aqui mostrados (caso 1: valor de retorno1; caso 2: valor de retorno2; caso 3: valor de retorno3... Uma pessoa adequada colocaria todos os valores numa matriz e obteria apenas o valor requerido pelo seu índice. E para a tarefa inversa, utilizaria a pesquisa binária.
Sou duas mãos a favor de bom código com arrays. Mas ao escrever um NormalizeDouble mais rápido do que o normal, encontrei um efeito optimizador - uma boa solução via const-array era muito mais lenta do que uma complicada via switch-case. Deixei a segunda variante porque o NormalizeDouble é muito utilizado no testador. Coloquei-o no indicador e não olho para este monstro. Mas os testes de fundo são mais rápidos.
Lembro-me de uma vez ter havido um fio de discussão, em que os criadores só falavam da implementação como uma pesquisa binária, o que, claro, é muito mais lento do que o simples acesso por índice calculado.Mas agora parecem tê-lo feito mais sabiamente: se um passo é constante, o índice é calculado, caso contrário é feita uma pesquisa binária. É claro que a implementação nativa é sempre mais rápida do que o embrulho.
Naturalmente, isto depende das suas prioridades. Mas imho, se a velocidade é tão crucial que se está pronto para inventar muletas, então também se deve desistir de OOP e MQL ;) Embora eu tenha a certeza que com uma codificação adequada esta diferença de velocidade não será tão significativa. E usa-o de forma mais racional em código real, não é verdade?
Lembro-me de uma vez ter havido um fio de discussão, em que os programadores só falavam da implementação como uma pesquisa binária, o que, claro, é muito mais lento do que o simples acesso por índice calculado.Mas agora parecem tê-lo feito mais sabiamente: se o passo é constante, então o índice é calculado, caso contrário a pesquisa binária. É claro que a implementação nativa é sempre mais rápida do que o embrulho.
O compilador, se não for burro, teria de transformar a const-array e a única referência do tipo pelo índice em código de comutação.
É claro que poderá ter de depender das suas prioridades. Mas imho, se a velocidade é tão crucial que se está pronto para inventar muletas, então deve desistir de OOP e MQL em geral ;) Embora esteja certo de que com a codificação correcta a diferença de velocidade não será tão substancial. Ao testar medições está simplesmente a correr uma função através de um loop milhões de vezes. E em código real, usa-o mais racionalmente, não é verdade?
O compilador, se não for burro, deveria ter transformado a const-array e a única referência de tipo a ela por índice em código de comutação.
Então a matriz é apenas uma constante? E a estática? E porquê "mudar o código"? É uma operação simples: comparar o valor do índice com o tamanho do array/enum, e se for menos, obter o endereço do elemento requerido como endereço do array + índice, e depois ler o valor a partir daí. Pensei que tal disparate devia ser compilado igualmente.
Então a matriz é apenas uma constante? E a estática? E porquê "mudar o código"? É uma operação simples: comparar o valor do índice com o tamanho do array/enum, e se for menos, obter o endereço do elemento requerido como endereço do array + índice, e depois ler o valor a partir daí. Pensei que tais disparates deviam ser compilados da mesma forma.
Não me lembro ao certo se podem criar arrays estáticos usando métodos constantes - certamente que não o podem fazer. Por uma questão de princípio, eu estava a fazer consortes e não estática. Contando com a inteligência do compilador. Após a compilação, não deveria ter havido qualquer indício de uma matriz nas tripas. Um statik é uma estrutura muito mais complicada do que constante. É por isso que eu tinha a certeza de que o compilador não iria conseguir lidar com o statik. Mas eu teria de tentar.
Não me lembro exactamente se as arrays estáticas podem ser feitas const. métodos - definitivamente não. Por uma questão de princípio, eu estava a fazer consortes, não estática. Contando com a inteligência do compilador. Após a compilação, não deveria ter havido qualquer indício de uma matriz nas tripas. Um statik é uma estrutura muito mais complicada do que constante. É por isso que eu tinha a certeza de que o compilador não iria conseguir lidar com o statik. Mas eu teria de tentar.
Oh, bem, isso explica tudo. Não deve confiar na inteligência excessiva do compilador, que optimiza ainda mais uma solução mal concebida para si. Se você mesmo é demasiado preguiçoso para o fazer correctamente, dizendo que "a estática é muito mais complicada" (embora o que lá é complicado, não compreendo), então porquê acusar o compilador?
Oh, bem, isso explica tudo. Não deve confiar na inteligência excessiva do compilador, uma vez que optimizará uma solução mal concebida para si. Se você mesmo foi demasiado preguiçoso / não pensou em fazê-lo correctamente, dizendo "a estática é muito mais complicada" (embora o que lá é complicado, não compreendo), então porquê acusar o compilador?
De nada. Vai ensinar-me uma lição para o futuro, que eu deveria pensar 7 vezes, antes de andar por aí a inventar muletas).
Acontece agora, que elogiei a mudança, ou melhor, os seus criadores demasiado cedo. Assim, tudo é aí implementado apenas através de pesquisa binária, mesmo quando a enumeração vai com múltiplos. Não é bom.
De nada. Será uma lição para o futuro, pensar 7 vezes antes de correr e inventar muletas).