Características da linguagem mql5, subtilezas e técnicas - página 110
![MQL5 - Linguagem para estratégias de negociação inseridas no terminal do cliente MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Fórum sobre comércio, sistemas automatizados de comércio e testes de estratégia comercial
Insectos, insectos, perguntas
fxsaber, 2018.12.01 11:15
Desenho de super-freioUm ficheiro de 40Mb de 1 milhão de linhas leva 18 segundos para ser lido.
O mesmo resultado de saída, mas feito de forma diferente
Já está feito em 0,5 segundos.
Uma simples contrapartida ao auto_ptr (considerado obsoleto). Nota: não muito análogo, com
...
https://habr.com/post/140222/
pavlick_
Uma linha no início deve ser adicionada a operator=:
Embora provavelmente valha a pena limitar-se a algo como isto (não se pode copiar de todo):
Porque é que fiz uma cópia para o auto_ptr? Devido à curvatura do µl - para copiar um objecto de pilha para o CArrayObj é necessário criar um monte de objectos, chamando ao construtor um monte de vezes. Mas acho que não vale a pena. A este respeito, retirarei o primeiro posto.Porque é que fiz uma cópia para o auto_ptr? Devido à curvatura μl - para copiar um objecto de pilha para o CArrayObj é necessário criar um monte de objectos, chamando ao construtor um monte de vezes.
E porquê "a curvatura de μl"?
E porquê a "tortuosidade do µl"?
A tarefa trivial de adicionar uma cópia de um objecto de pilha a um array é adicionar um construtor por defeito, do qual não precisava em primeiro lugar:
Não é fatal, sim, pode fazer init() no Q, o que vai suavizar um pouco o problema, mas continua a ser nojento. E quando se copia auto_ptr na mão, tudo acontece em duas linhas, mas o jogo não vale a pena o esforço. Talvez demasiado picuinhas, perfeccionismo.
A tarefa trivial de adicionar uma cópia de um objecto de pilha a um array acaba por ser esta + eu preciso de prescrever um construtor por defeito, do qual eu não precisava de todo:
Não é fatal, sim, pode fazer init() no Q, o que vai suavizar um pouco o problema, mas continua a ser nojento. E quando se copia auto_ptr na mão, tudo acontece em duas linhas, mas o jogo não vale o esforço. Talvez demasiado picuinhas, perfeccionismo.
Mas é exactamente o mesmo em C++ também, por isso não é realmente claro porque é que o mcl torto.
E no seu caso é mais fácil especificar o construtor de cópias, e adicionar elementos com uma linha:
ar.Add(new Q(q));
A tarefa trivial de adicionar uma cópia de um objecto de pilha a um array acaba por ser esta + eu preciso de escrever um construtor por defeito, do qual não precisava de forma alguma:
Não é fatal, sim, pode fazer init() no Q, o que vai suavizar um pouco o problema, mas continua a ser nojento. E quando se tem cópia auto_ptr, tudo acontece em duas linhas, mas o jogo não vale o esforço. Talvez demasiado picuinhas, perfeccionismo.
É assim que tudo acontece de qualquer maneira - está apenas escondido atrás do seu auto_ptr...
Não vejo aqui nenhum problema especial.
Como um temporizador antigo endurecido, não gosto muito da abordagem C# onde a memória é apagada automaticamente. Na minha opinião, foi a pessoa que solicitou a eliminação de objectos, e não alguns "coleccionadores de lixo" que deveriam ser responsáveis por ela.
Mas é exactamente o mesmo em C++, por isso não é muito claro porque é que o mcl está torto.
E no seu caso é mais fácil especificar um construtor de cópias, e adicionar elementos numa só linha:
Como é que é o mesmo? Há lá um construtor de cópias automaticamente e todas as manipulações terão um olhar:
E no seu caso é mais fácil definir o construtor de cópias e adicionar elementos com uma linha
Claro que é uma classe de brinquedos, por exemplo, na realidade são também alguns dados, provavelmente muitos, não é uma opção para escrever um construtor de cópias. Embrulhado nos locais certos em invólucros e sem necessidade de um construtor à medida.
Por isso, tudo acontece de qualquer maneira - está apenas escondido atrás do seu auto_ptr...
Não vejo aqui qualquer problema em particular.
Como um temporizador antigo endurecido, não gosto da abordagem C# onde a memória é apagada automaticamente. Na minha opinião, a pessoa que solicitou a eliminação de objectos deve ser responsável por ela, e não algum coleccionador de lixo.
Em µl, pode prescindir de apontadores inteligentes. Colector de lixo != apontadores inteligentes, não se pode passar sem eles, pelo menos por causa de excepções. Eu próprio não gosto de coleccionadores de lixo.