Errori, bug, domande - pagina 2724

 
Slava :

No. FileFlush deve essere fatto se si vuole che qualcun altro possa leggere il file modificato

Il problema è che il programma MQL5 legge il file nel proprio buffer quando lo apre. E non sa che qualcosa è cambiato nel file finché non legge di nuovo il file. Il file può essere letto di nuovo solo chiudendo e poi aprendo quel file

Gloria, è esattamente questo il problema. Guardate il link che ho postato sopra, troverete il codice per riprodurlo.

Lo stesso file si apre dallo stesso EA, 1 descrittore per scrivere, 2 per leggere, il fileflush è usato dopo la scrittura, prova a leggere e non funziona correttamente.

Naturalmente, se si chiude/apre funziona, ma allora non c'è bisogno di usare FileFlush.

 
Alain Verleyen:

Gloria, questo è esattamente il problema. Date un'occhiata al link che pubblico sopra, troverete il codice per riprodurlo.

Lo stesso file si apre dallo stesso consulente, 1 descrittore per la scrittura, 2 per la lettura, il fileflush è usato dopo la scrittura, prova a leggere, e non funziona correttamente.

Naturalmente se si chiude/apre funziona, ma allora non c'è bisogno di usare FileFlush.

Capisco il problema che descrive.

Il 1° EA scrive il file. Potrebbe non chiudere quel file, ma in questo caso dovrebbe chiamare FileFlush

Il 2° Expert Advisor legge il file. Dovrebbe aprire il file ogni volta e poi chiuderlo.

Aprire e chiudere il file solo per il secondo EA!

 
Slava:

È esattamente quello di cui sto parlando. Chiudere, poi riaprire

O intendi FileFlush prima di chiudere il file?

Sì, è necessario risciacquare prima della chiusura? O la sua chiusura garantisce la pertinenza del file registrato.

 
Andrey Barinov :

Sì, è necessario risciacquare prima della chiusura? O la chiusura assicura che il file registrato sia aggiornato.

Il risciacquo è inutile se si chiude subito dopo.
 
Slava :

Capisco il problema che descrive.

Il 1° EA scrive il file. Potrebbe non chiudere il file, ma in questo caso dovrebbe chiamare FileFlush

Il 2° Expert Advisor legge il file. Deve aprire il file ogni volta e poi chiuderlo.

Apertura e chiusura del file solo per il secondo EA!

Capisco che questo è un workaround.

Ma sarebbe meglio correggere l'errore, non è possibile facilmente, suppongo?

 
Andrey Barinov:

Sì, è necessario risciacquare prima della chiusura? O la chiusura assicura che il file registrato sia aggiornato.

Non necessariamente. I buffer vengono resettati automaticamente se non è stata fatta una chiamata a FileFlush prima della chiusura

 

Il bug MT5 (build 2390) conta erroneamente le parentesi graffe nella descrizione della struttura della classe.

class A{};
class B : public A};  // Ok

class C : public A   

void OnStart()
{
   A a;
}                      // Compile Error: '}' - unexpected end of program        
 
Slava:

Un Expert Advisor che legge un file deve tenere questo file chiuso.

La particolarità dell'implementazione dei file in MQL5 è che mantengono i dati dei file nei propri buffer il più possibile. Se la dimensione delle informazioni è così grande da non entrare nel buffer, il tuo trucco di spostare il puntatore all'inizio e poi alla fine del file potrebbe funzionare.

Quindi al momento apri il file, controlla il suo contenuto, poi chiudilo di nuovo

Come ho detto sopra (nel tuo stesso testo), è viceversa nel mio test-case - l'indicatore legge, Expert Advisor scrive. Ma per quanto ho capito, il tipo di programma non è importante. Il problema è architettonico.

L'implementazione del file specificato in MQL5 è un bug. Chiudere e aprire un file è un workaround, ma non dovrebbe essere così per leggere un file condiviso.

Occuparsi dell'ottimizzazione delle prestazioni è un bene, ma non dovrebbe influire negativamente sulla funzionalità.

PS. Come soluzione rapida e sporca, ecco un suggerimento: in risposta a una chiamata FileFlush per un file aperto in lettura - aggiornate il suo buffer.

 
Vict:

Probabilmente perché µl C++ è simile, e le strutture sono arrivate lì dal C.

Se avete bisogno di costruttori, usate le classi o date il benvenuto a Sharp. Perché privare le strutture di questa connotazione? Questo non farà altro che rendere i programmi più espressivi. Posso prendere il codice di qualcuno e vedere che ha una struttura invece di una classe e ottenere molte informazioni da una sola parola. Non otterrete nulla, studierete diligentemente il codice sorgente per ottenere lo stesso risultato, che ho ottenuto in un batter d'occhio. Nella mia esperienza - questa convenzione di strutture è rispettata, bene, forse una specie di marginalità nichilista del vento.

Ma in C++ strutture e classi sono la stessa cosa. Ecco perché tutti i vostri ragionamenti sull '"espressività del codice" non influiscono sull'essenza delle cose. Sipuò anche definire qualsiasi altra parola espressiva tranne struct o class attraverso un define e non cambierà nulla (intendo C++).

Questo è il motivo per cui dovremmo parlare di strutture solo dal punto di vista di C#. È da lì che viene preso il loro concetto. Le strutture sono tipi di valore, quindi sono molto più compatte delle classi, non sono polimorfe e non possono essere referenziate. Quest'ultimo è particolarmente importante.

Non c'è nessun male, ti sembra. C'è anche uno standard esteso: leggere unsigned char non inizializzati e std::byte non è un comportamento indefinito. Potete usare l'inizializzazione aggregata per POD. E non dimenticate - tutta questa inizializzazione non è gratuita, è un vero consumo di risorse (CPU, memoria, dimensione di un eseguibile). Se non ve ne frega un cazzo con il vostro scribacchino di numeri, nel caso di qualche microcontrollore può essere importante. Dopo tutto, C/C++ non è solo un fattore di forma Windows come Sharp.

L'inizializzazione di una sola variabile ha aumentato la dimensione delle istruzioni del 30%.

Nessuno dice che l'inizializzazione è libera di per sé, ma uno ne avrebbe bisogno comunque, quindi non capisco bene il significato delle tue misure con e senza inizializzazione.

Un'altra cosa è che il compilatore non reinizializzerà le variabili:

int a= 0;  // Эту инициализацию компилятор вырежет
//...
a= 10;

Quindi tutta questa paranoia di aver paura della preinizializzazione delle variabili è ridicola. Questo è il 2020, soprattutto se si parla di strutture POD. La loro inizializzazione è sicuramente ottimizzata dal compilatore.

L'assenza di preinizializzazione è accettabile solo quando c'è un controllo del compilatore al 100% che proibisce la lettura di variabili non inizializzate.

 
Alexey Navoykov:

In C++, strutture e classi sono la stessa cosa. Quindi tutti i vostri argomenti sull '"espressività del codice" non toccano l'essenza delle cose.Si può anche definire qualsiasi altra parola espressiva che non sia struct o class attraverso un define e non cambierà (intendo C++)

Che testardo ))), è la stessa cosa per te, non hai bisogno di definire qualcosa con un define, c'è già una parola - struct. Puoi ignorarlo, ma poi non sorprenderti che i codificatori decenti ti guardino come un codificatore di merda quando vedono le tue strutture piene di funzioni. Forse è stato un errore agli albori delle croci equiparare strutture e classi, si sarebbero dovute lasciare le strutture come in C.

Ecco perché dovremmo parlare di strutture solo dal punto di vista di C#. È da lì che viene preso il loro concetto. Le strutture sono tipi di valore, quindi sono molto più compatte delle classi, non sono polimorfe e non possono essere referenziate. Quest'ultima cosa è particolarmente importante.

Pensi che il tuo Sharp sia apparso in un campo pulito? Radicata in C, la struttura è un contenitore muto senza zucchero extra.

Un'altra cosa è che il compilatore non reinizializzerà le variabili:

int a= 0;  // Эту инициализацию компилятор вырежет
//...
a= 10;

Quindi tutta questa paranoia di aver paura della preinizializzazione delle variabili è ridicola. Questo è il 2020, soprattutto se si parla di strutture POD. La loro inizializzazione è sicuramente ottimizzata dal compilatore.

Come può essere così sicuro? Chiamare una funzione da un'altra unità di traduzione/un altro modulo/cicli/il compilatore è fuori sintonia/... . Non sopravvalutate le capacità dell'ottimizzatore. Questa non è l'ottimizzazione Copy elision che i compilatori sono obbligati a fare. Se gli ottimizzatori diventano così intelligenti e smette di costare qualcosa, scriveranno nel prossimo standard C: "l'inizializzazione di default non lascia un oggetto in stato indefinito".
Motivazione: