Questions sur la POO dans MQL5 - page 65

Nouveau commentaire
 
Sergey Dzyublik:

Quelque chose que vous avez oublié à propos des structures et des classes (sans nouvelles) - elles se distinguent toutes deux sur la pile.

À ne pas confondre avec le C++, il est plus proche du Sharp.

 
Maxim Kuznetsov:

À ne pas confondre avec le C++, il est plus proche du Sharp.

C'est votre fantasme, pas la réalité.
Vous ne devriez pas prouver ce que vous n'avez pas testé vous-même...
La création de variables locales comme objets de structures et de classes (sans new) se fait sur la pile.
J'ai décrit précédemment lefonctionnement des tableaux dans MT5.

 
Dmitry Fedoseev:

Quelle poisse !

1 - Par la création d'objets. 2 - simplement par un appel de fonction normal. Le premier chiffre est le temps en millisecondes, ne faites pas attention au second.

Il est presque 10 fois plus rapide (et parfois plus de 10 fois). C'est triste... empilement... pile... ***cha

Eh bien, pourquoi ne pas y prêter attention ? Laissez-moi deviner : INT_MAX a effectué une fois une action via la création d'un objet temporaire, et ensuite la même action via un appel de fonction ?

Eh bien, c'est un résultat attendu, étant donné que nous sommes toujours en train de danser autour de la création de la classe dans le runtime (nous devrions toujours obtenir ce handle qui ressemble à un index dans un conteneur).

PS. Où est le code source pour le replay ?

PPS. Êtes-vous sûr que la fonction a été appelée ? De toute façon, l'optimiseur est aussi dans ce code, pas le fait qu'il y aura un appel de fonction en cours d'exécution :

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

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

Le fait que UB dans mql est là - prouve ce code :

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:

Le fait que mql ait UB prouve ce code :

Vous avez habilement enroulé le compilateur autour de votre doigt :
- false branch est lancé parce qu'il n'y a pas de rupture de la boucle while(1).
- true est retourné car les opérations sont effectuées sur des variables locales sans aucune interaction avec le "monde extérieur" et l'exécution de ce code est également rejetée.

 
Sergey Dzyublik:

Vous avez habilement enroulé le compilateur autour de votre doigt :
- la fausse branche est lancée parce qu'il n'y a pas de rupture de la boucle while(1).
- true est retourné car les opérations sont effectuées sur des variables locales sans aucune interaction avec le "monde extérieur" et l'exécution de ce code est également rejetée.

Ce n'est pas moi - c'est un des exemples sur Internet. C'est la même chose que pour les "plus".

 
Vladimir Simakov:

Pourquoi ne pas faire attention ? Laissez-moi deviner : INT_MAX a effectué une fois une action via la création d'un objet temporaire et ensuite la même action via un appel de fonction ?

Eh bien, c'est un résultat attendu, en tenant compte du fait que nous sommes toujours en train de danser autour de la création de la classe dans le runtime (nous devrions obtenir ce handle qui ressemble à un index dans un conteneur).

PS. Où est le code source pour le replay ?

PPS. Êtes-vous sûr que la fonction a été appelée ? De toute façon, l'optimiseur est aussi dans ce code, pas le fait qu'il y aura un appel de fonction en cours d'exécution :

Le fait que UB soit dans mql prouve ce code :

Vous avez tort. Il n'est pas nécessaire de deviner ici, il suffit de se souvenir de la journée d'hier. En cas de problèmes de mémoire, vous pouvez consulter les citations pour savoir sur quoi portait la conversation. Pourquoi le résultat est-il devenu soudainement attendu, alors qu'auparavant vous prétendiez le contraire ?

Oui, je suis sûr que la fonction a été appelée. Et vous aimez tous rêver que je suis un idiot ? Pourquoi la question ne porte que sur la fonction, et peut-être que l'objet n'a pas été créé non plus ? Ou êtes-vous si sûr de savoir comment fonctionnent tous les compilateurs ?

 
Sergey Dzyublik:

Pouvez-vous m'expliquer de quoi il s'agit, parce que je suis un peu bête, je l'ai lu trois fois - mais je ne comprends toujours pas...

Regardez les citations et voyez de quoi nous parlons. Ce que j'ai cité, et en réponse à ce que je recevais cette réponse de la citation.

 
et toutes les conversations que vous avez eues ont tourné en de telles absurdités... à propos de la pile, à propos de la chaîne du tableau... Votre explication par "sur la pile" ne fonctionne pas.
 

Comme Dimitri était trop gêné pour poster son code, j'ai dû faire 15 minutes de tests moi-même.

Oups. Avec des opérations identiques, la différence n'est que de 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 différence de temps d'exécution persiste même sans toute cette agitation avec les variables et les champs statiques. C'est la différence en microsecondes, pas le pourcentage.

Conclusion : le coût de la création d'un objet temporaire sur la pile est suffisamment faible sur mon ordinateur, qui n'est pas le plus rapide, pour être d'environ 30-40 ns/pc (nanoseconde), et je devrais donc y prêter attention dans la plupart des cas.

PS. Et je pensais du mal des développeurs, mais non, il ne faut pas prendre les gens au mot et les vérifier))).

 
Vladimir Simakov:

Comme Dimitri était trop gêné pour poster son code, j'ai dû faire 15 minutes de tests moi-même.

Oups. Avec des opérations identiques, la différence n'est que de 30%.

La différence de temps d'exécution persiste même sans toute cette agitation avec les variables et les champs statiques. C'est la différence en microsecondes, pas le pourcentage.

Conclusion : le coût de la création d'un objet temporaire sur la pile est suffisamment faible sur mon ordinateur, qui n'est pas le plus rapide, pour être d'environ 30-40 ns/pc (nanoseconde), et je devrais donc y prêter attention dans la plupart des cas.

PS. Et je pensais du mal des développeurs, mais non, il ne faut pas croire les gens sur parole et les vérifier ;)))

Et même plus faire toutes sortes de calculs différents à l'intérieur, la différence sera encore plus faible. Quoi qu'il en soit, ce test peut difficilement être qualifié de test de fonctionnalité identique.

En outre, les tests eux-mêmes ne sont pas identiques.

1...585960616263646566676869707172...96
Nouveau commentaire
Raison: