Mt4 Fim do apoio. - página 29
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
A principal desvantagem: O OOP força você a seguir o caminho da fragmentação do código em muitas funções.
É mais fácil para os humanos aceitar códigos fragmentados, mas a fragmentação é contra-indicada a qualquer mecanismo.
Tudo bem, mas qual é a desvantagem?
É a principal vantagem, justamente porque é mais fácil para uma pessoa perceber um código fragmentado!
O computador tem que se adaptar ao humano, não o humano ao computador.
Isso mesmo, mas qual é a desvantagem?
Essa é a principal vantagem, justamente porque é mais fácil para uma pessoa perceber um código fragmentado!
O computador deve adaptar-se à pessoa, não a pessoa ao computador.
Infelizmente, um desenvolvedor deveria pensar na eficiência de seu mecanismo antes de tudo, não em seu conforto)).
Caso contrário, o mecanismo "coxeará".
O desenvolvedor deve se ajustar ao computador.
Se as citações vierem do mesmo servidor, não faz diferença qual instrumento. Afinal de contas, as barras são abertas simultaneamente em cada instrumento.
É diferente se as fontes de cotações estiverem em diferentes partes do mundo. Por minutos não importa, mas pode haver um problema com prazos mais altos. Talvez as funções de tempo precisem ser estudadas com mais detalhes e a correção de tempo precisa ser feita. Mas essa é a próxima etapa no desenvolvimento dessa solução...
Você precisa fazer uma calibração para esta função...
No início eu queria ler tudo o que foi escrito sem mim, caso já houvesse uma pergunta e uma resposta, mas temo que será difícil encontrar o posto que precisa ser citado mais tarde.
Por enquanto há apenas uma pergunta: Como todos sabem, uma nova barra não aparecerá até o primeiro tique no novo intervalo de tempo. Portanto, se houver uma barra por milissegundos mas ela estiver ausente, você pode obter leituras indicadoras da barra errada.
Espero encontrar uma resposta para a segunda pergunta, ela foi feita pela Artem.
No início eu queria ler tudo o que foi escrito sem mim, caso já houvesse uma pergunta e uma resposta, mas temo que será difícil encontrar o posto que precisa ser citado.
Até agora apenas 1 pergunta: Como todos sabem, uma nova barra não aparecerá até o primeiro tique no novo intervalo de tempo. Portanto, se houver uma barra por milissegundos, mas ela estiver ausente, podemos obter valores indicadores da barra errada.
Espero encontrar uma resposta para a segunda pergunta, ela foi feita pela Artem.
Sim, discutimos isso ontem.
Eu costumava lidar com outra plataforma e havia barras formadas pelo tempo, independentemente da chegada das citações (veja TWS).
Foi-me dito que não é o caso da MT.
Acrescentarei um cheque de chegada de orçamento para confirmar o evento de aparecimento de um novo bar.
Eu já respondi que os bares abrem independentemente da chegada de uma cotação. Se não houver cotação, o preço da nova barra será o preço de fechamento da barra anterior. O fato de uma nova barra será fixado independentemente da chegada das citações, pelos próprios balcões, que funcionam com um cronômetro.
O cronograma específico não importa, pois é apenas um contador que atinge seu valor e estabelece o evento da nova barra de tempo daquele cronograma. Este é simplesmente um método de sincronização com o aparecimento de novas barras de diferentes intervalos de tempo. SINCRONIZAÇÃO.
O instrumento também não importa. Se as citações forem de um servidor, isso significa que elas têm o mesmo tempo de aparecimento de novos bares. Portanto, não importa qual instrumento, desde que esses instrumentos sejam de um ponto do globo.
Vou terminar o que eu disse e fazer outras coisas. Um pouco de coisas boas).
E como se pode explicar que o fechamento da sexta-feira, a barra anterior de qualquer período é igual a 1,20333, e a abertura da segunda-feira de qualquer período é igual a 1,20142?
Claro que esta é a citação de um corretor, a outra pode ser um pouco diferente, mas há uma diferença em todos.
E como você explica o fato de que a sexta-feira está fechada, a barra anterior de qualquer período é 1.20333 e a segunda-feira aberta de qualquer período também é 1.20142?
É claro que estas são as citações de um corretor, o outro pode ser um pouco diferente, mas todos eles têm diferenças.
Isso é explicado pela lacuna. Isso acontece na abertura da sessão.
Não sou especialista em comércio, portanto, não julgue minha opinião de forma muito dura).
E eu sei ainda menos sobre o que acontece no mercado forex).
Infelizmente, o projetista deve pensar primeiro na eficiência de seu mecanismo, não em seu conforto).
Caso contrário, o mecanismo "coxeará".
O desenvolvedor tem que se ajustar ao computador.
Não.
Deixe o computador se ajustar a mim. Já tenho outros problemas suficientes. O desenvolvedor só pode fazer ajustes onde o computador não consegue lidar com a tarefa, digamos, em gargalos onde lhe falta desempenho ou memória. Então, sim, é a vez de o desenvolvedor se ajustar. Mas até agora não encontrei nenhum lugar onde o OOP impusesse uma carga adicional tão significativa no computador que teria que ser reduzida de alguma forma.
Algo parecido (código para MQL5):
Mas repito - eu sou um apoiador do OOP.
É apenas um exemplo realmente mal sucedido para mostrar o que é impossível de fazer na programação de procedimentos.
Quando comecei isto, não pretendia mostrar que nada é possível/impossível de se fazer, mas apenas mais conveniente de usar no futuro ao escrever meus próprios códigos.
Mas afinal, como disse o V.S., eu queria o melhor, mas acabou sendo como sempre.
Oh, não.
É o computador que se ajusta a mim. Já tenho outros problemas suficientes. O desenvolvedor só pode se ajustar onde o computador "não consegue lidar", digamos, em "gargalos", onde não há desempenho ou memória suficiente. Então, sim, é a vez de o desenvolvedor se ajustar. Mas até agora não encontrei nenhum lugar onde o OOP forneça uma carga adicional tão significativa no computador que ele deva ser de alguma forma reduzido.
A carga no computador é causada pela atitude descuidada do desenvolvedor em relação à questão da coerência de seu mecanismo. Um desejo de economizar energia para melhorar o sistema. Um desperdício irrazoável de recursos de informática em nome da facilidade de seu trabalho.
Enquanto o computador lidar com o código escrito de forma ineficiente, o desenvolvedor continuará a "parasitar" o poder de processamento. Esta é uma estrada sem saída.
Mais cedo ou mais tarde, o mecanismo ineficaz deixará de se desenvolver e será substituído por um homólogo melhor.
O tempo e o esforço do homem serão desperdiçados e sua cria acabará no caixote do lixo.
No mundo competitivo, este risco existe o tempo todo.
Quando projetamos máquinas, devemos pensar primeiro em seu desempenho, e no conforto e conveniência de passar nossas horas de trabalho em segundo lugar).
O ônus é colocado no computador pela atitude negligente do desenvolvedor em relação à coerência de seu mecanismo. Um desejo de economizar energia para melhorar o sistema. Consumo exagerado de recursos informáticos em nome da facilitação de seu trabalho.
Enquanto o computador lidar com o código escrito de forma ineficiente, o desenvolvedor continuará a "parasitar" o poder de processamento. Esta é uma estrada sem saída.
Mais cedo ou mais tarde, o mecanismo ineficaz deixará de se desenvolver e será substituído por um homólogo melhor.
O tempo e o esforço do homem serão desperdiçados e sua cria acabará no caixote do lixo.
No mundo competitivo, este risco existe o tempo todo.
Enquanto desenvolvemos mecanismos, devemos pensar em seu desempenho em primeiro lugar e no conforto e conveniência de nosso horário de trabalho em segundo lugar)).
Chama-se escrever o programa. É por isso que um código que funcione corretamente (e que possa ser lido por qualquer outro desenvolvedor) é escrito primeiro e só depois é otimizado - se houver algo que possa ser otimizado.