Erros, bugs, perguntas - página 1409
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
Relativamente ao anúncio da nova construção 1200.
Tais soluções parecem muito crocantes quando se adiciona tempo_msclongo à estrutura juntamente com ahorada data. A questão é então porque é que o tempo é necessário? É um desperdício sem sentido de recursos.
O mesmo é verdade para as bandeiras deuint enquantouchar seria suficiente lá ou, pelo menos, ushort (que com uma reserva significativa para o futuro). E porque é que uint é necessário lá está para além da compreensão.O que é triste é que os criadores deixaram completamente de pensar no armazenamento racional de dados. Uma série de carraças é um tamanho colossal por si só. E aqui a memória está a ser desperdiçada de forma tão descuidada...
Seja como for, falando de tempo. Talvez seja altura de introduzir no MQL um tipo de tempo normal que contenha milissegundos, ou então teremos apenas estas muletas.Tanto mais que a própria data na sua forma actual é uma coisa muito irracional: consome 8 bytes mas contém apenas segundos - e quem precisa dela? 4 bytes(uint) são suficientes para esta tarefa durante os próximos 90 anos (e Duncan McLeod não está entre nós).
Esta solução preserva a compatibilidade com programas mais antigos que utilizam tempo em segundos ou SymbolInfoTick().
Acreditem na nossa experiência, o jogo "vamos fazê-lo num byte ou dois" leva a problemas monstruosos no futuro. Só o compreende quando escreve software para os 10 anos seguintes.
Os 4 bytes de data em segundos terminarão em 2038 (mais 22 anos), e não em 90 anos.
O que é que TM=30M significa aqui?
Na nossa experiência, o jogo "vamos fazer dele um byte ou dois" leva a problemas horrendos no futuro. Só se dá conta disto quando se escreve software com 10 anos de antecedência.
É claro que devemos deixar alguma margem para o futuro, mas dentro de limites razoáveis. Por exemplo, no caso que estamos a discutir, o campo das bandeiras armazena informações apenas sobre seis outros campos. Se o fizer do tipo "ushort", terá mais 10 campos a acrescentar. Quanto mais pode acrescentar?
Se pretende guardar um copo cheio, por exemplo, 32 bits não são suficientes. Porque não fazê-lo 64 bits de uma só vez? Embora, obviamente, para um copo necessitará de uma estrutura muito diferente.
Claro que compreendo que 2 bytes extra não é muito significativo, mas acontece que 2 bytes aqui, 2 bytes ali... ...e isso soma-se a muito.
4 bytes de data em segundos terminam em 2038 (outros 22 anos), não em 90 anos.
Digo-vos - vocês sofrerão com estruturas económicas não extensíveis, começarão a pensar em termos de décadas, necessidade de apoio prolongado e tudo se tornará claro.
Com 4 bytes de datatime, as massas de software terão grandes problemas com transbordamentos apenas em 2038, o que levará a uma reescrita frenética do código antigo. E os transbordos serão apanhados ainda mais cedo em operações de tapetes e deltas.
Estou a programar há 25 anos e sei do que estou a falar. Tenho escrito programas rentáveis durante toda a minha vida. Veja os nossos terminais - são verdadeiras obras-primas pela quantidade de funcionalidade contida em ficheiros exe de tamanho reduzido. Executar um único terminal.exe nú num computador limpo e ver o que acontece.
Mas as coisas mudaram agora - ou se escreve código de 64 bits com uma margem em quase todo o lado ou se fica de fora do futuro. Isto é especialmente importante para nós, uma vez que não estamos a libertar caixas fechadas, mas sim plataformas de desenvolvimento com um requisito de compatibilidade.
Dentro de alguns anos estaremos a dar pontapés em nós próprios porque nos veremos novamente sub-investidos. E todos à volta são computadores com dezenas de gigabytes em equipamento básico.
O que é que TM=30M significa aqui?
Com 4 bytes de data/hora a maioria do software terá grandes problemas com transbordamentos apenas em 2038, o que levará a uma reescrita frenética do código antigo. E os transbordos serão apanhados ainda mais cedo em operações de tapetes e deltas.
Refere-se aos códigos MQL4? (em que a data/hora foi originalmente baseada em int). Depois, é claro, outra conversa relacionada com problemas de compatibilidade. Mas eu estava originalmente a falar de racionalidade. Por isso, neste caso, a racionalidade sofre.
Contudo, em qualquer caso, penso que concordará que é necessário um novo tipo de tempo contendo milissegundos e que não deve começar a partir de 1970, mas muito mais cedo, por exemplo, a partir de 1900. Já não se trata apenas de forex. Os câmbios já existem há muito tempo.
...
Contudo, em qualquer caso, penso que concordará que é necessário um novo tipo de tempo, um tempo que contenha milissegundos. E não deve começar em 1970, mas muito mais cedo, por exemplo, em 1900. Não estamos a falar apenas de forex agora, mas as trocas já existem há muito tempo.
O único problema é que não estava na moda utilizar computadores sob o Czar Gorokh e a história das carraças não foi preservada para as gerações futuras...
Não se trata necessariamente de carraças. Por exemplo, as velas do dia ainda estão intactas.
Tenho vergonha de perguntar, porque precisa dos preços dos castiçais diários durante 1900... anos? Para fazer análises técnicas? Para testar os Conselheiros sobre a história?
A velocidade de execução aumentará de 2 para 10 vezes para versões x64 do terminal MetaTrader 5.
O resultado vale bem a pena. Embora ainda iremos trabalhar sobre a velocidade de compilação.
Recentemente gabou-se de que a velocidade da MQL está próxima de C++. E agora acontece que vai ultrapassar C++ por várias vezes? ))
Se conseguir obter esta velocidade em alguns testes especialmente preparados, isso não significa que a obterá noutros casos também. Mas a velocidade de compilação está a abrandar em todos os casos.