Lavorare con i file. - pagina 5

[TheXpert]

Yedelkin:

Domanda 1: Pensi che ci sia un errore di battitura nella documentazione, e che invece di "Last Read Date" dovrebbe dire qualcosa come "Last Open Date"?

Sì, ecco il verbatim:

lpLastAccessTime [out, opzionale]

Un puntatore a una strutturaFILETIME per ricevere la data e l'ora dell'ultimo accesso al file o alla directory. L'ultimo tempo di accesso include l'ultima volta che il file o la directory è stato scritto, letto o, nel caso di file eseguibili, eseguito.

Traduzione libera -- l'ultimo accesso include l'ultima volta che il file è stato letto o scritto o eseguito (se eseguibile).

Probabilmente mi sbaglio sull'override della maniglia, ma c'è anche questo testo interessante:

Non tutti i file system possono registrare i tempi di creazione e di ultimo accesso e non tutti i file system li registrano nello stesso modo. Per esempio, su FAT, il tempo di creazione ha una risoluzione di 10 millisecondi, il tempo di scrittura ha una risoluzione di 2 secondi, e il tempo di accesso ha una risoluzione di 1 giorno (in realtà, la data di accesso). Pertanto, la funzioneGetFileTime potrebbe non restituire le stesse informazioni sul tempo del file impostate con la funzione SetFileTime.

NTFS ritarda l'aggiornamento dell'orario dell'ultimo accesso di un file fino a un'ora dopo l'ultimo accesso. NTFS permette anche di disabilitare gli aggiornamenti del tempo di ultimo accesso. L'ultimo tempo di accesso non è aggiornato sui volumi NTFS per impostazione predefinita.

Nella situazione attuale, la felicità è attesa quando le proprietà dei file vengono recuperate senza "riaprire" l'handle.

A quanto pare, nessuna fortuna, almeno non quando si tratta di secondi.

[Yedelkin]

TheXpert:

Sì, ecco il verbatim:

Traduzione libera -- l'ultimo accesso include l'ultima volta che il file è stato letto o scritto o eseguito (se eseguibile).

Probabilmente mi sbaglio sull'override della maniglia, ma c'è anche questo testo interessante:

A quanto pare non c'è questa fortuna, almeno non quando si tratta di secondi.

Grazie per l'ampliamento della mente! Già... Che peccato.

Questo script dice che invece di "Last read date" l'identificatore FILE_ACCESS_DATE restituisce l'ora dell'ultima chiusura del file:

int handle_file;
void OnStart()
  {
   Print("===============================================");
   handle_file=FileOpen("Ye_file2.bin",FILE_READ|FILE_WRITE|FILE_BIN);
   switch(handle_file)
     {
      case  INVALID_HANDLE: break;
      default:
         Print("Дата создания файла Ye_file2.bin: ",(datetime)FileGetInteger(handle_file,FILE_CREATE_DATE));
         for(int i=0;i<3;i++)
           {
            Sleep(2000);
            FileReadInteger(handle_file,CHAR_VALUE);
            Print("Дата последнего чтения Ye_file2.bin: ",(datetime)FileGetInteger(handle_file,FILE_ACCESS_DATE));
           }
         Sleep(3000);
         Print("Время обращения к FileClose(handle_file): ",TimeTradeServer());
         FileClose(handle_file);
     }
  }

[Yedelkin]

TheXpert:

Ma nonostante le conclusioni selvagge, i test sono rivelatori, quindi aspettiamo i commenti degli sviluppatori su come funziona la funzione quando non ci sono cambiamenti.

A proposito, negli ultimi tre mesi non ho ricevuto alcun commento, quindi evito di usareFileFlush() per il momento.

[Михаил Янович]

Mi sembra che FileFlush non dovrebbe rallentare/accelerare il programma se viene usato al posto di FileClose.

Non ha senso usarlo in loop per ogni record. Immaginate quanto sarebbe lento Word se salvasse di nuovo ogni volta che un documento viene modificato (specialmente se quel documento ha molto testo e immagini). FileFLush facilita solo il salvataggio senza chiudere i file.

Gli sviluppatori devono aver voluto dire che (per esempio):

OnInit - FileOpen

Su Tick - FileWrite FileFlush

(e qui i dati vengono salvati -FileFlash- nel ciclo, non ad ogni passaggio del ciclo, ma dopo che il ciclo è finito)

OnDeinit FileClose.

Lo scopo di FileFlash è quello di scriverci dentro tutto il tempo in cui l'Expert Advisor è in esecuzione, in modo da non reinizializzare costantemente l'handle del file e il mistico buffer del file.

......niverse)

[TheXpert]

Yedelkin:
A proposito, non ho ricevuto alcun commento negli ultimi tre mesi, quindi ho evitato di usare FileFlush() per il momento.

Non garantisce comunque il salvataggio immediato. Quindi ha senso usarlo solo per salvare lo stato attuale senza chiudere l'handle.

[is_vale]

Yedelkin:

A proposito, non ho ricevuto alcun commento negli ultimi tre mesi, quindi ho evitato di usare FileFlush() per il momento.

Per capire meglio il significato dell'uso della funzione FileFlush(), dobbiamo pensare al concetto di buffer di input/output dei file... Come sapete le informazioni su disco sono memorizzate in byte e scrivere ogni byte individualmente (come arriva) è il massimo dello spreco! Se si guarda questo processo dal lato "hardware", allora ad ogni richiesta di operazione di scrittura di byte, il sistema operativo dovrebbe "muovere la testa dello scrittore" dell'hard disk! E un disco rigido è cinematico! In altre parole, è il più lento di tutti i dispositivi informatici. Allora qual è la soluzione? Una soluzione molto semplice! Nella memoria del computer viene creato un buffer di dati (di solito è qualche decina di kilobyte) in cui vengono inviati i dati dalla funzione FileWrite e simili. Non appena questo buffer sarà completamente riempito, il sistema lo scrive completamente su un disco rigido come il blocco continuo di dati, così non viene eseguita una manipolazione inutile della testina del disco, e i dati vengono semplicemente scritti in UNA MACCHINA! Ora calcola quante volte aumenta la velocità di scrivere 32 kilobyte di informazioni alla volta rispetto a scrivere ogni byte separatamente della stessa dimensione ;) E il calcolo è abbastanza semplice... Per ogni operazione di scrittura viene posizionata prima la testa del drive, poi viene eseguita l'operazione di scrittura. E questo senza entrare in tutto il duro lavoro di un'operazione di lettura/scrittura :) Nel caso di un buffer, posizioniamo la testa del drive una volta e scriviamo l'intero blocco in un unico flusso!

Ma tutto ciò detto, finché il vostro buffer non è pieno, i vostri dati non appariranno fisicamente nel file (!!!), o finché non chiudete il file stesso, nel qual caso il buffer (o meglio ciò che vi è rimasto) viene scritto sul disco immediatamente. È qui che entra in gioco la funzione FileFlush. Quando avete "scritto" alcune informazioni nel file e avete bisogno che appaiano nel file (per esempio, queste informazioni possono essere già utilizzate da un altro programma, indicatore, Expert Advisor...), allora potete chiamare la funzione FileFlush, che scaricherà fisicamente il contenuto del buffer sul disco (su un file)!

Conclusione: l'uso frequente della funzione FileFlush o il suo utilizzo nei cicli, per accelerare il lavoro con il file, darà proprio il risultato opposto, perché ad ogni chiamata, il sistema deve calcolare la quantità di informazioni, effettivamente contenute nel buffer I/O, chiamare il sistema operativo e dare il comando per scrivere questa sezione di memoria nel file! Per esempio, il ciclo scrive un byte nel file e chiama immediatamente la funzione FileFlush, otteniamo il modo più lento di scrivere su disco BACKGROUND!!! ;)

Quindi qual è il modo più veloce per scrivere su un file? Molto semplice ;) Non scherzare e tortura FileFlush :) In questo caso si ottiene uno scambio di dati veloce tra FileWrite e gli appunti (la manipolazione della memoria è la più veloce). Il sistema controllerà l'overflow in questo buffer e, se necessario, trasmetterà i dati (l'operazione più veloce con un dispositivo così goffo come un disco rigido!) e cancellerà il buffer per ricevere nuovi dati!!!

Poi sorge la domanda: "Perché abbiamo bisogno della funzione FileFlush??". E la risposta è semplice: è necessario quando è necessario che i dati siano scritti fisicamente nel file, indipendentemente dal riempimento del buffer. Ho dato un esempio di tale necessità sopra.

[is_vale]

Ho dovuto riscrivere il mio indicatore per MQL5 e ho incontrato una seria confusione :(

Ecco il codice:

  first_bar=ChartGetInteger(0,CHART_FIRST_VISIBLE_BAR,0);
  
  //--- установим доступ к массиву как к таймсерии
  ResetLastError();
  int copied=CopyTime(NULL,0,0,first_bar,TimeAsSeries);
  del();
  int handle=FileOpen("Price Label\\"+_Symbol+tpl_ext,FILE_READ|FILE_CSV,';',CP_ACP);
  int er=GetLastError();
  ResetLastError();
  
  string sTF="";
  int TF;
  string period_name;
  string price_label;
  string price1;
  string price2;
  
  if (handle>=1){
    while(FileIsEnding(handle)==false){
      sTF = FileReadString(handle);
      TF = ResolveTF(sTF);
      period_name=FileReadString(handle);
      price_label=FileReadString(handle);
      price1=FileReadString(handle);
      price2=FileReadString(handle);
      drawe_price(TF,handle,period_name,price_label,price1,price2);
    }
    FileClose(handle);
  }
  return(0);

Voglio spiegare subito che ho inserito un numero così grande di variabili per vedere cosa succede nel debugger. E ho visto...

Il file contiene un mucchio di stringhe, ogni stringa ha 5 sezioni divise da ";". La prima chiamata

sTF = FileReadString(handle);

mette l'intero file nella variabile sTF, in una codifica incomprensibile. A giudicare da quello che vedo nel debugger (nella variabile STF legge il contenuto del file come unicode! Quando ho aperto il file, ho provato tutte le pagine di codice disponibili, ma il risultato è lo stesso :( Il file stesso è scritto in codifica Windows.

Qualcuno ha idea di dove sia sepolto il cane?

[Yedelkin]

è_vale

Grazie a tutti per aver condiviso le informazioni! Mi immergerò di nuovo nell'argomento.

[TheXpert]

FILE_ANSI

[Yedelkin]

is_vale:

Qualcuno ha idea di dove sia il problema?

È da molto tempo che non lavoro con le operazioni sui file... Guarda, quando usi FileOpen() hai un file CSV dichiarato. Serve a specificare che tutti gli elementi scritti sono convertiti in stringhe unicode o ansi. Forse è qui che si trova il cane?