Domande su OOP in MQL5 - pagina 65

Nuovo commento
 
Sergey Dzyublik:

Qualcosa che hai dimenticato sulle strutture e le classi (senza nuovo) - entrambe si distinguono sullo stack.

Da non confondere con C++, è più vicino a Sharp

 
Maxim Kuznetsov:

Da non confondere con C++, è più vicino a Sharp

Questa è la vostra fantasia, non la realtà.
Non dovresti provare ciò che non hai testato tu stesso...
La creazione di variabili locali come oggetti di strutture e classi (senza new) avviene sullo stack.
Ho descritto prima comefunzionano gli array in MT5.

 
Dmitry Fedoseev:

Che sfortuna!

1 - Attraverso la creazione di oggetti. 2 - semplicemente attraverso una normale chiamata di funzione. Il primo numero è il tempo in millisecondi, non fate attenzione al secondo.

È quasi 10 volte più veloce (e a volte più di 10 volte più veloce). Che cosa triste... pila... mucchio... ***cha

Beh, perché non prestare attenzione? Fammi indovinare: INT_MAX una volta ha eseguito un'azione tramite la creazione di un oggetto temporaneo, e poi la stessa azione tramite una chiamata di funzione?

Beh, è un risultato atteso, considerando che stiamo ancora ballando intorno alla creazione della classe nel runtime (dovremmo ancora ottenere questo handle che sembra un indice in qualche contenitore).

PS. Dov'è il codice sorgente per il replay?

PPS. Siete sicuri che la funzione sia stata chiamata? Comunque, l'ottimizzatore è anche in questo codice, non il fatto che ci sarà una chiamata di funzione in run-time:

for (int i=0;i<500;++i){
   int x=Get(i);}

int Get(int x) {return -x;}

Il fatto che UB sia in mql dimostra questo codice:

void OnStart(){
   Print(Test()?"Ok":"No");
}

bool Test (void)
{
  const int MAX = 1000;
  int a=1,b=1,c=1;
  while (1) {
    if (((a*a*a) == ((b*b*b)+(c*c*c)))) return true;
    a++;
    int x=Get(a);
    if (a>MAX) {
      a=1;
      b++;
    }
    if (b>MAX) {
      b=1;
      c++;
    }      
    if (c>MAX) {
      c=1;
    }
  }
  return false;
}
 
Vladimir Simakov:

Il fatto che mql abbia UB dimostra questo codice:

Hai abilmente avvolto il compilatore intorno al tuo dito:
- il ramo falso viene lanciato perché non c'è una pausa dal ciclo while(1).
- true viene restituito perché le operazioni vengono eseguite su variabili locali senza alcuna interazione con il "mondo esterno" e anche l'esecuzione di questo codice viene gettata via.

 
Sergey Dzyublik:

Hai abilmente avvolto il compilatore intorno al tuo dito:
- il falso ramo viene lanciato perché non c'è una pausa dal ciclo while(1).
- true viene restituito perché le operazioni vengono eseguite su variabili locali senza alcuna interazione con il "mondo esterno" e anche l'esecuzione di questo codice viene gettata via.

Non sono io - è uno degli esempi su Internet. È lo stesso dei plus.

 
Vladimir Simakov:

Perché non prestare attenzione? Fammi indovinare: INT_MAX ha eseguito una volta un'azione tramite la creazione di un oggetto temporaneo e poi la stessa azione tramite una chiamata di funzione?

Bene, questo è un risultato atteso, tenendo conto che stiamo ancora ballando intorno alla creazione della classe nel runtime (dovremmo ottenere questo handle che sembra un indice in qualche contenitore).

PS. Dov'è il codice sorgente per il replay?

PPS. Siete sicuri che la funzione sia stata chiamata? Comunque, l'ottimizzatore è anche in questo codice, non il fatto che ci sarà una chiamata di funzione in run-time:

Il fatto che UB sia in mql dimostra questo codice:

Ti sbagli. Non dovete indovinare qui, ricordatevi solo che ieri, in caso di problemi di memoria, potete guardare tra le citazioni per vedere di cosa tratta la discussione. Perché il risultato è diventato improvvisamente atteso, se prima sosteneva il contrario?

Sì, sono sicuro che la funzione è stata chiamata. E a tutti voi piace sognare che io sia un idiota? Perché la domanda riguarda solo la funzione, e forse anche l'oggetto non è stato creato? O sei così sicuro di sapere come funzionano tutti i compilatori?

 
Sergey Dzyublik:

Puoi spiegare di cosa si tratta, perché sono un po' tonto, l'ho letto tre volte - ma ancora non l'ho capito...

Guarda le citazioni e vedi di cosa stiamo parlando. Quello che ho citato, e in risposta a quello che stavo ottenendo questa risposta dalla citazione.

 
e ogni conversazione che hai avuto si è trasformata in queste sciocchezze... sullo stack, sulla stringa dell'array... La tua spiegazione attraverso "sulla pila" non funziona.
 

Poiché Dimitri era troppo imbarazzato per postare il suo codice, ho dovuto fare 15 minuti di test io stesso.

Ops. Con operazioni identiche la differenza è solo del 30%.

class CTest{
   static uint count;
   static double temp;
   int i;
public:
   CTest(int _x):i(_x){++count; temp+=(double)GetMicrosecondCount(); temp/=count;}
   ulong Get() {return GetMicrosecondCount()+i;}
   static uint Count()  {return count;}
   static double Temp() {return temp;}
};

int i=1;
double temp;

uint CTest::count=0;
double CTest::temp=0.0;

void OnStart(){
   ulong t=GetMicrosecondCount();
   for (;i<1000001;++i){
      temp+=(double)CTest(i).Get();
      temp/=i;}
   ulong _t=GetMicrosecondCount()-t;
   Print(_t," | ",i);
   Print(CTest::Count());
   Print(CTest::Temp());
   t=GetMicrosecondCount();
   for (;i<2000001;++i){
      temp+=(double)Test(i);
      temp/=i;}
   _t=GetMicrosecondCount()-t;
   Print(_t," | ",i);
   Print(temp);
}

ulong Test(int x) {
   static uint count=0;
   static double _temp=0.0;
   ++count;
   _temp+=(double)GetMicrosecondCount();
   _temp/=count;
   return GetMicrosecondCount()+x;}

La differenza di runtime persiste anche senza tutto questo casino con variabili statiche e campi. È la differenza in microsecondi, non la percentuale.

Conclusione: il costo della creazione di un oggetto temporaneo sullo stack è abbastanza piccolo sul mio computer non il più veloce da essere circa 30-40 ns/pc (nanosecondo), quindi dovrei farci caso nella maggior parte dei casi.

PS. E ho pensato male degli sviluppatori, ma no, semplicemente non bisogna prendere le persone in parola e controllarle)))

 
Vladimir Simakov:

Poiché Dimitri era troppo imbarazzato per postare il suo codice, ho dovuto fare 15 minuti di test io stesso.

Ops. Con operazioni identiche la differenza è solo del 30%.

La differenza di runtime persiste anche senza tutto questo casino con variabili statiche e campi. È la differenza in microsecondi, non la percentuale.

Conclusione: il costo della creazione di un oggetto temporaneo sullo stack è abbastanza piccolo sul mio computer non il più veloce da essere circa 30-40 ns/pc (nanosecondo), quindi dovrei farci caso nella maggior parte dei casi.

PS. E ho pensato male degli sviluppatori, ma no, basta non prendere la parola delle persone e controllarle)))

E anche più fare tutti i tipi di calcoli diversi all'interno, la differenza sarà ancora meno. Comunque, questo test difficilmente può essere chiamato un test di funzionalità identica.

Inoltre, i test stessi non sono identici.

1...585960616263646566676869707172...96
Nuovo commento