Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
Vasiliy!
Non ho aspettato una tua risposta. (non so se MQ ha avuto il tempo di implementare i cambiamenti nella build 1100)
Decoder:
Richiami:
Vasiliy!
Non ho aspettato una tua risposta. (non so se MQ ha avuto il tempo di implementare i cambiamenti nella build 1100)
Decoder:
Richiami:
Mikalas, è possibile rendere il codice di decodifica e codifica come una libreria con un controllo per il completamento dello spacchettamento?
Certo. Questo è quello che farò nel prossimo futuro. Ci sarà da imballare/disimballare. Aggiunta e rimozione di file dall'archivio. La cosa principale è che CryptDecode non fallisce.
Vasiliy!
L'imballaggio ZIP è necessario?
Non credo che ne valga la pena.
1. Se vuoi costruire un database basato su ZIP, non sarà rilevante.
Presto MQ aggiungerà funzioni standard per lavorare con il database (Renat ha fatto un sondaggio).
2. Non puoi risolvere il problema con file di dimensioni maggiori di uint.
Ci dovrebbe essere la compressione ZIP64 per le dimensioni ulong.
3. Non sai esattamente come vengono compressi i dati di MT5
È possibile che file di grandi dimensioni (anche di dimensione uint)
I file di grandi dimensioni (anche di dimensioni uint) saranno compressi per ORE!
4. Per "stipare" i file in un archivio, dovrete tenere un bel po' di informazioni in
un sacco di informazioni in memoria - ci sarà HARDWARE!
Lo sconsiglio vivamente....
Probabilmente sto pensando alla vecchia maniera, ma per me l'archiviazione è interessante per accelerare il trasferimento dei dati su Internet. Localmente, con dischi rigidi di grandi dimensioni, la dimensione del file perde la sua rilevanza, e il database sarà per una gamma limitata di persone, ed è costoso da implementare, in quanto richiederà ulteriori conoscenze da parte del programmatore e dell'utente.
È vero che zip è notevolmente inferiore a rar nella compressione, soprattutto del testo - il che è un po' triste.
Vasiliy!
L'imballaggio ZIP è necessario?
Non credo che ne valga la pena.
Io penso il contrario.
1. Se vuoi costruire un database basato su ZIP, non sarà rilevante.
Presto MQ aggiungerà funzioni standard per lavorare con i database (Renat ha fatto un sondaggio)
No, zip non è interessante come alternativa a DB. Non è per questo che vale la pena preoccuparsi della zip.
2. Non potete risolvere il problema con file di dimensioni maggiori di uint.
Ci deve essere la compressione ZIP64 per le dimensioni ulong.
Non ho l'obiettivo di creare un analogo di WinZip o WinRar. Solo gli archivi più elementari. Nessuno penserà mai a comprimere file più grandi di 4 GB.
3. Non sai come esattamente vengono compressi i dati di MT5.
È possibile che file di grandi dimensioni (anche di dimensioni uint) siano
anche uint size) sarà compresso per ORE!
4. Per "stipare" i file in un archivio, dovrete tenere un bel po' di informazioni in
un sacco di informazioni in memoria - ci sarà HARDWARE!
Consiglio vivamente contro....
1. MQ non fa funzioni lente, e se lo fa, le ottimizza in modo tempestivo, in base alle richieste di servicedesk. Sono in qualche modo fiducioso che CryptEncode volerà.
2. Non ci saranno rallentamenti. Non sapete di cosa sia capace un moderno MQL5 in termini di prestazioni. I computer di oggi hanno troppa memoria. Scaricare e impacchettare un file di un paio di centinaia di megabyte è un gioco da ragazzi, e non avete bisogno di altro. Perché questi sono altri compiti.
Vasiliy!
L'imballaggio ZIP è necessario?
Non credo che ne valga la pena.
Io penso il contrario.
No, zip non è interessante come alternativa a DB. Non è per questo che vale la pena preoccuparsi della zip.
Non ho l'obiettivo di creare un analogo di WinZip o WinRar. Solo gli archivi più elementari. Nessuno penserebbe mai di comprimere file più grandi di 4 GB.
1. MQ non fa funzioni lente, e se lo fa, ottimizza il loro lavoro in modo tempestivo, in base alle richieste del service desk. Sono in qualche modo fiducioso che CryptEncode volerà.
2. Non ci saranno rallentamenti. Non sapete di cosa sia capace un moderno MQL5 in termini di prestazioni. I computer di oggi hanno troppa memoria. Scaricare e impacchettare un file di un paio di centinaia di megabyte è un gioco da ragazzi, e non avete bisogno di altro. Perché questi sono altri compiti.
Probabilmente sto pensando alla vecchia maniera, ma per me l'archiviazione è interessante per accelerare il trasferimento dei dati su Internet. Localmente, con dischi rigidi di grandi dimensioni, la dimensione del file perde la sua rilevanza, e il database sarà per una gamma limitata di persone, ed è costoso da implementare, in quanto richiederà ulteriori conoscenze da parte del programmatore e dell'utente.
Il vero zip è significativamente inferiore nella compressione, specialmente del testo, rar - il che è un po' triste.
Abbastanza vero. Comunicare con un server di terze parti tramite WebRequest sarà molto più veloce utilizzando il confezionamento delle informazioni inviate. Questa è un'altra idea per cui ricaricare l'imballaggio è una buona soluzione.
Tuttavia, zip è significativamente inferiore a rar nella compressione, specialmente del testo - il che è un po' spiacevole.
Apprezzare ciò che ci è stato dato. Credetemi, la capacità di lavorare con il formato di compressione più popolare copre il 90% di tutti i compiti. L'80% della ridondanza viene eliminata con successo con zip. Quello che viene dopo è la caccia ai pappagalli di cui nessuno ha bisogno.
Che liberazione!