Erros, bugs, perguntas - página 2724
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
Não. FileFlush deve ser feito se quiser que outra pessoa possa ler o ficheiro modificado
O problema é que o programa MQL5 lê o ficheiro no seu próprio buffer quando o abre. E não sabe nada sobre nada ter mudado no ficheiro até voltar a ler o ficheiro. O ficheiro só pode ser lido novamente fechando e depois abrindo esse ficheiro
Glória, esse é exactamente o problema. Por favor, veja o link acima, encontrará o código para o reproduzir.
O mesmo ficheiro abre a partir do mesmo EA, 1 descritor para escrever, 2 para ler, fileflush é utilizado após a escrita, tenta ler e não funciona correctamente.
Claro, se fechar/abrir funciona, mas depois não há necessidade de utilizar FileFlush.
Glória, este é exactamente o problema. Por favor, veja o link que publico acima, encontrará o código para o reproduzir.
O mesmo ficheiro abre a partir do mesmo conselheiro, 1 descritor para escrever, 2 para ler, fileflush é utilizado após a escrita, tenta ler, e não funciona correctamente.
É claro que se fechar/abrir funciona, mas depois não há necessidade de utilizar FileFlush.
Compreendo o problema que descreve.
A 1ª EA escreve o ficheiro. Pode não fechar esse ficheiro, mas nesse caso deve chamar FileFlush
O 2º Conselheiro Especialista lê o ficheiro. Deve abrir o ficheiro de cada vez, depois fechá-lo.
Abra e feche o ficheiro apenas para a segunda EA!
É exactamente disso que estou a falar. Fechar, depois reabrir
Ou quer dizer FileFlush antes de fechar o ficheiro?
Sim, é necessário puxar o autoclismo antes de fechar? Ou o seu encerramento garante a relevância do ficheiro gravado.
Sim, é necessário puxar o autoclismo antes de fechar? Ou o encerramento garante que o ficheiro registado está actualizado.
Compreendo o problema que descreve.
A 1ª EA escreve o ficheiro. Pode não fechar o ficheiro, mas, neste caso, deve chamar FileFlush
O 2º Conselheiro Especialista lê o ficheiro. Tem de abrir o ficheiro de cada vez, e depois fechá-lo.
Abrir e fechar o ficheiro apenas para a segunda EA!
Compreendo que se trata de uma solução de trabalho.
Mas seria melhor corrigir o erro, não é possível facilmente, suponho?
Sim, é necessário puxar o autoclismo antes de fechar? Ou o encerramento garante que o ficheiro registado está actualizado.
Não necessariamente. Os amortecedores são reiniciados automaticamente se nenhuma chamada FileFlush tiver sido feita antes do fecho
O Bug MT5 (build 2390) conta incorrectamente os suportes encaracolados na descrição da estrutura da classe.
Um consultor especializado que leia um ficheiro deve manter este ficheiro fechado.
A peculiaridade da implementação de ficheiros na MQL5 é que guardam os dados dos ficheiros nos seus próprios buffers tanto quanto possível. Se o tamanho da informação é tão grande que não cabe no buffer, o seu truque de mover o ponteiro para o início e depois para o fim do ficheiro pode funcionar.
Portanto, de momento abra o ficheiro, verifique o seu conteúdo e depois feche-o novamente
Como disse acima (no seu próprio texto), é o contrário no meu caso de teste - o indicador lê-se, escreve o Expert Advisor. Mas, tanto quanto sei, o tipo de programa não é importante. O problema é arquitectónico.
A implementação do ficheiro especificado em MQL5 é um bug. Fechar e abrir um ficheiro é uma alternativa, mas não deve ser assim para ler um ficheiro partilhado.
Cuidar da optimização do desempenho é bom, mas não deve afectar negativamente a funcionalidade.
PS. Como uma solução rápida e suja, eis uma sugestão: em resposta a um pedido de FileFlush para um ficheiro aberto para leitura - actualizar o seu buffer.
Provavelmente porque µl C+++ é semelhante, e as estruturas vieram de C.
Se precisar de construtores, use classes ou seja bem-vindo à Sharp. Porque privar as estruturas desta conotação? Isto só irá tornar os programas mais expressivos. Posso pegar no código de alguém e ver que ele/ela tem uma estrutura em vez de uma classe e obter muita informação a partir de apenas uma palavra. Não obterá nada, estudará diligentemente o código fonte para obter o mesmo resultado, o que obtive num piscar de olhos. Na minha experiência - esta convenção de estruturas é respeitada, bem, talvez algum tipo de marginalismo niilista do vento.
Mas em C++ as estruturas e classes são uma e a mesma coisa. É por isso que todo o seu raciocínio sobre a "expressividade do código" não afecta a essência das coisas.Pode também definir qualquer outra palavra expressiva excepto estrutura ou classe através de uma definição e não mudará nada (quero dizer C++).
É por isso que devemos falar de estruturas apenas do ponto de vista do C#. É daí que o seu conceito é retirado. As estruturas são tipos de valores, por isso são muito mais compactas do que as classes, não são polimórficas, e não podem ser referenciadas. Esta última é especialmente importante.
Não há ali nenhum mal, parece-vos. Há mesmo um padrão alargado: leitura de cartas não assinadas não inicializadas e std::byte não é um comportamento sem ser detectado. Pode utilizar a inicialização agregada para a POD. E não se esqueça - toda esta inicialização não é gratuita, é um verdadeiro consumo de recursos (CPU, memória, tamanho de um executável). Se não quer saber disso com o seu crocante de números, no caso de algum microcontrolador pode ser importante. Afinal de contas, C/C++ não é apenas um factor de forma do Windows como Sharp.
A inicialização de uma única variável aumentou o tamanho das instruções em 30%.
Ninguém diz que a inicialização é livre por si só, mas de qualquer forma precisaríamos dela, por isso não compreendo bem o significado das suas medições com e sem inicialização.
Outra coisa é que o compilador não vai reinicializar variáveis:
Portanto, toda esta paranóia de se ter medo da pré-inicialização variável é ridícula. Estamos em 2020, especialmente se se falar de estruturas de POD. A sua inicialização é certamente optimizada pelo compilador.
A ausência de pré-inicialização só é aceitável quando existe um controlo de 100% do compilador que proíbe a leitura de variáveis não-inicializadas.
Em C++, estruturas e classes são uma e a mesma coisa. Assim, todos os seus argumentos sobre a "expressividade do código" não afectam a essência das coisas.Pode também definir qualquer outra palavra expressiva mas estruturante ou classe através de uma definição e ela não mudará (quero dizer C++)
Que pessoa teimosa ))), é a mesma coisa para si, não precisa de definir nada por uma definição, já existe uma palavra - estrutura. Pode ignorá-lo, mas depois não se surpreenda que codificadores decentes o vejam como um codificador de merda quando virem as suas estruturas recheadas de funções. Talvez tenha sido um erro na aurora das cruzes equacionar estruturas e classes, deveria ter deixado estruturas como em C.
É por isso que devemos falar de estruturas apenas do ponto de vista do C#. É daí que o seu conceito é retirado. As estruturas são tipos de valor, por isso são muito mais compactas que as classes, não são polimórficas, e não podem ser referenciadas. Este último é especialmente importante.
Acha que a sua Sharp apareceu num campo limpo? Enraizada em C, a estrutura é um recipiente estúpido sem açúcar extra.
Outra coisa é que o compilador não vai reinicializar variáveis:
Portanto, toda esta paranóia de ter medo da pré-inicialização variável é ridícula. Estamos em 2020, especialmente se estiver a falar de estruturas POD. A sua inicialização é certamente optimizada pelo compilador.