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
Ha lasciato solo la variante 0-INT_MAX nei robot da combattimento. Ha smesso di notare i freni.
Cosa farete poi con questa storia?
Naturalmente posso cambiare il sottoconto ogni mese per limitare la cronologia degli ordini a qualche centinaio di migliaia, ma questa non è la soluzione :)
Cosa farete poi con questa storia?
Potrei naturalmente cambiare il sottoconto ogni mese per limitare la cronologia degli ordini a centomila, ma non è la soluzione :)
Al momento vedo che nel 99% dei casi si deve usare solo HistorySelect(0, INT_MAX). Cerca di non usare le altre opzioni.
Probabilmente basta non spostare l'inizio della cache, cioè fare sempre la query dalla stessa data (e se è 0 è irrilevante).
Dobbiamo controllare.
Probabilmente basta non spostare l'inizio della cache, cioè fare sempre la query dalla stessa data (e se è 0 è irrilevante).
Ha bisogno di essere controllato.
Possibilmente. È difficile essere un tester per molto tempo.
Risultato.
Su ogni zecca c'è un problema.
SZY ha installato Win10, LatencyMon mostra che tutto è a posto.
Perché fai finta di essere così ingenuo?
Stai cercando di dimostrare che non va bene uccidere la cache, è colpa tua. È colpa vostra se state uccidendo la cache di una grande storia. Ed è solo un tuo problema modificare di proposito la tua posizione. Si possono trovare molte opportunità di uccidere/cancellare un mucchio di cache in ambiente MQL5.
Non ti aiuteremo - in qualsiasi linguaggio di programmazione ci sono un numero enorme di opzioni per spararsi nel piede e nella testa.
Saresti trattato normalmente se indicassi esplicitamente "guarda - questo sono io che avveleno la cache di proposito e mi sparo".Probabilmente basta non spostare l'inizio della cache, cioè fare sempre la query dalla stessa data (e se è 0 è irrilevante).
Ha bisogno di essere controllato.
Questo è esattamente quello che ho descritto esplicitamente.
Se stai campionando per data, non cercare di fare un campione diverso per ogni richiesta. E con fino ad oggi cercare di metterlo avanti.
Noi controlliamo specificamente la posizione e la riduciamo automaticamente a INT_MAX se supera o eguaglia la data attuale.
Stai cercando di dimostrare che l'uccisione della cache non è la norma, sia prima che adesso. È colpa tua se hai ucciso la cache di una grande storia. Ed è solo un vostro problema per modificare specificamente una posizione. Si possono trovare molte opportunità di uccidere/cancellare un mucchio di cache in ambiente MQL5.
Una libreria usa HistorySelect di TimeCurrent. L'altro è da zero. Perché cazzo dovrei entrare nelle viscere delle librerie per scoprire che non sono compatibili tra loro per le prestazioni?
Un esempio succinto è capire perché librerie innocue possano interferire tra loro. Infine, impegnate il vostro pensiero critico.
Una libreria usa HistorySelect di TimeCurrent. L'altro è da zero. Perché cazzo si dovrebbe entrare nelle viscere delle librerie per scoprire che non sono compatibili tra loro per le prestazioni?
Un esempio succinto è capire perché librerie innocue possano interferire tra loro. Accendi finalmente il tuo pensiero critico.
È così incasinato che è un tuo problema personale che usi le biblioteche e spegni la testa.
È un tuo problema del cazzo usare le biblioteche e spegnere la testa.
Perché non vai a scrivere tutto da zero in Asm da solo? Si scopre che va bene quando ciascuna delle librerie vola separatamente. Ma non appena si inizia a usarli entrambi contemporaneamente, si comincia a diventare pigri.
Abbiamo segnalato con successo dei bug a Microsoft, ma non abbiamo mai scritto o accusato loro che ci sono circa N milioni di opportunità per ucciderci sulle loro API.
Soprattutto mentre si usano le biblioteche di altre persone nel processo.