Errori, bug, domande - pagina 2754

[A100]

fxsaber:

Il punto è poter passare per riferimento.

Così come con le stringhe, gli sviluppatori hanno l'opportunità (se non l'hanno già fatto) di passare tutto per riferimento senza copiare effettivamente la variabile.

void f()
{
        MqlTick tick;
        SymbolInfoTick( NULL, tick );
        g( tick );
}

inline void SymbolInfoTick( string symbol, MqlTick& tick )
{
      tick = _LastTick; //л енивое программирование: а не будем ничего копировать,
                        //пока _LastTick не изменится
}

E sarà una soluzione non per una particolare strutturaMqlTick, ma per tutte le occasioni

[Ilyas]

A100:

Il che conferma ancora una volta che non ha sensousare direttamente _Digits,_Point , _Period, _LastError, ecc. (e anche _Symbol può essere sostituito da NULL). Infatti, devono essere dichiarati come const volatile

E voi, al contrario, proponete di allargare questa gamma

Hai ragione, ma sonoquasi volatili, tranne il flag IsStopped - è volatile al 100%, cioè qualsiasi lettura di IsStopped è una lettura della memoria al 100%.
Per altri,quasivollatylе significa che il compilatore PUÒ mettere in cache il valore di una variabile in un registro alla prima chiamata e usare il valore in cache la prossima volta che si accede a tale variabile, ma solo all'interno di una funzione o ramo di chiamate, se sono delineate in una funzione.
Questo è possibile (e necessario) perché cambiare le variabili predefinite (eccetto IsStopped) non può avvenire all'interno di un punto di ingresso MQL (funzione OnXXX)

Per quanto riguarda il MODIFICATORE DIVARIABILI, diciamo che è usato da programmatori di costruttori per programmatori.
Come sappiamo, si può cambiare la costante di una variabile attraverso la conversione, quindi non ci si può fidare del compilatore con il modificatore const.
Se il compilatore vede che la variabile non ha cambiato il suo valore ed è inizializzata come una costante, trasformerà tale variabile in un valore immediato (ImmediateValue) anche senza il modificatore const

. Per quanto riguarda _LastTick, stiamo discutendo ma...
Questa è una struttura, non un semplice tipo atomico e può essere cambiata all'improvviso, in qualsiasi punto del programma MQL, compreso il momento di ottenere il valore.
Si scopre che per affrontare questa struttura è necessario introdurre un sincronizzatore.

Stiamo lavorando costantemente sulle prestazioni, in particolare, a causa di questo alto tasso di rilascio delle build.
Abbiamo in programma di fare molto lavoro per velocizzare il codice MQL

[Igor Makanu]

Ilyas:

Per quanto riguarda _LastTick, stiamo discutendo, ma...

Questa è una struttura, non un tipo semplice-atomico e può essere cambiata improvvisamente, in qualsiasi punto del programma MQL, compreso il momento di ottenere il valore.
Si scopre che per affrontare questa struttura abbiamo bisogno di introdurre un sincronizzatore.

ma nel tester _LastTick non può cambiare in nessun punto del programma MQL?

se sì, allora date tale soluzione solo per i tester, dove la velocità dei calcoli è più importante

[Alexey Navoykov]

Igor Makanu:

ma nel tester _LastTick non può cambiare in nessun punto del programma MQL?

se sì, allora date una tale soluzione solo per il tester dove la velocità di calcolo è più importante

Quindi, cosa impedisce di richiedere questo tick una sola volta nel gestore OnTick, e poi di lavorare con i dati ottenuti? Non costa praticamente nulla. Perché dovrei richiederlo 100 volte (come nei test di cui sopra), creando artificialmente dei freni su un posto pari? Quindi, si suggerisce di risolvere il problema di un codice EA storto complicando il lavoro interno di MT. O hai delle misure normali?

[fxsaber]

Alexey Navoykov:
Quindi, cosa vi impedisce di richiedere questo tick nel gestore OnTick una volta e poi lavorare con i dati ricevuti?

Le basse qualifiche dei creatori di EA con cui Market e Cloud sono caricati sono un ostacolo.

[Maxim Kuznetsov]

Alexey Navoykov:
Quindi, cosa impedisce di richiedere il tick una volta nel gestore OnTick, e di lavorare ulteriormente con i dati ricevuti? Non costa praticamente nulla. Perché richiederlo di nuovo 100 volte (come nei test di cui sopra), creando artificialmente dei freni sul posto? Quindi, il problema di un codice EA storto si propone di risolvere complicando il lavoro interno di MT. O hai delle misure normali?

Gli eventi che devono essere gestiti da "OnTick" sono ricevuti esternamente in una coda con priorità. In altri gestori, è utile assicurarsi che non si siano verificati tali nuovi eventi, altrimenti i dati del tick precedente non sono validi/aggiornati.

[Igor Makanu]

Alexey Navoykov:
Quindi cosa ti impedisce di richiedere questo tick una volta nel gestore OnTick e poi lavorare con i dati risultanti? È praticamente inutile. Perché preoccuparsi di richiederlo 100 volte (come nei test di cui sopra), creando artificialmente un freno sul posto.

Questo è esattamente quello che faccio nel tester

Alexey Navoykov:
Cioè il problema di un codice EA storto dovrebbe essere risolto complicando il funzionamento interno di MT. O hai delle misure normali?

Bene, il codice è determinato dalle comuni pratiche di codifica, guardate QB e l'uso delle linee di sicurezza in questi esempi

Non uso SB, ho misurato con un profilatore e cercato soluzioni per mesi, c'era un thread sui test di velocità, gettando in parte soluzioni alternative

la normalità della misurazione? è un pendio scivoloso che dovrà essere affrontato seriamente, sono contento della mia EA per l'ottimizzazione, c'era un passaggio a 18 mesi 6 sec, ora 2,5 sec , imho ho fatto un buon lavoro su me stesso ))))

[A100]

Secondo i materiali di .... sono sorte le seguenti considerazioni:

Dato che UninitializeReason() può essere chiamata in qualsiasi parte di un programma, in particolare in OnInit() (e se tale chiamata non era prevista, lo scopo potrebbe essere esteso)

Si suggerisce:

Se il valore della variabile _UninitReason è generato prima che OnDeinit() sia chiamato,

e se il motivo della precedente deinizializzazione dell'EA non può essere definito (REASON_PROGRAM, REASON_REMOVE, ecc.)

dovrebbe essere indefinito (-1) prima di questa chiamata. Questo è ora 0, cioè effettivamente REASON_PROGRAM

Se l'EA è completamente riavviato(REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, ecc.), allora

sembra possibile impostare la variabile _UninitReason su un valore appropriato (REASON_RECOMPILE, REASON_ACCOUNT, REASON_CLOSE, ecc.) quando si avvia una nuova istanza di un programma,

non 0 come attualmente, cioè effettivamente REASON_PROGRAM

Se un Expert Advisor viene parzialmente riavviato (REASON_CHARTCHANGE, ecc.), la variabile _UninitReason in OnInit() è ancora uguale al valore corrispondente (REASON_CHARTCHANGE, ecc.),

e nessun cambiamento è necessario

[Sergey Dzyublik]

Errore di compilazione di MT5 (build 2450) per la dichiarazione in avanti del metodo della classe template.

template<typename T>
class A{};


class B{
public:
   template<typename T>
   void test(A<T> &a);
};

template<typename T>
void B::test(A<T> &a){}   // 'test' - member function already defined with different parameters 


void OnStart(){ 
   B b;
} 

[Artyom Trishkin]

Quando si riavvia il terminale, scrive continuamente e senza sosta nel registro dei record

2020.05.24 03:36:03.342 HistoryBase     'GBPUSD' 1 invalid bars removed

Il tempo della barra della cronologia nel registro è in costante aumento. Il grafico giornaliero GBPUSD è aperto e si agita - zero, prima e seconda barra sono cancellate/create. E così gira e rigira.

Sono qui ad aspettare. Riempirà tutto l'SSD con questi registri o si fermerà alla fine...

Il registro di ieri è nel rimorchio.