Erreurs, bugs, questions - page 2748

Nouveau commentaire
 
Mihail Matkovskij:

Vous avez peut-être ce défaut :

(non corrigé par ME5(build 2390)) ** (nouveau) Debuger, StepInto (F11) et les points d'arrêt installés ne fonctionnent pas.

 
TheXpert:
Peut-être que votre structure de fichiers est si complexe que le débogueur ne peut pas associer un point d'arrêt, alors c'est le problème du débogueur.

Je pense que la structure des fichiers des éléments standard de l'interface utilisateur que j'utilise dans mon projet est encore plus complexe que mon travail. Il faudrait que je travaille très dur pour faire quelque chose comme ça. Mais tel qu'il est, prenez-le et utilisez-le, comme on dit. Si vous mettez tout ensemble, comme dans mon cas. Alors, effectivement, vous obtenez quelque chose de compliqué. Mais pour les programmes de course, c'est tout à fait normal.

 
fxsaber:

Au départ, cela a été évoqué.


À un certain stade, non seulement la partie relative du temps pris devient importante, mais aussi la partie absolue.

On s'est habitué à allouer des variables en C pendant un certain temps, et c'est une bonne habitude à prendre.

Dans la première fonction personnalisée, la structure MqlTick en entrée est transmise directement à la fonction MQL, sans aucune allocation de mémoire.
Une telle entrée est appelée mauvais codage.

bool GetCurrentTick1( MqlTick &Tick )
{
  return(SymbolInfoTick(_Symbol, Tick));
}

Dans le deuxième exemple, la variable CurrentTick est créée ; la mémoire lui est allouée.
Et cette entrée est considérée comme plus correcte.
Comme la mémoire est déjà allouée, les données d'entrée sont traitées plus rapidement, sans coûts inutiles.

bool GetCurrentTick2( MqlTick &Tick, const bool NewTick = false )
{
  static MqlTick CurrentTick;
  
  if (NewTick)
    SymbolInfoTick(_Symbol, CurrentTick);
  
  Tick = CurrentTick;
  
  return(true);
}
 
Roman:

Avec un peu plus de C, vous prendrez l'habitude d'allouer des variables.

Suivez votre propre conseil et vous aurez peut-être au moins une petite idée de l'affectation.
 
Roman:

...

Et ce dossier est considéré comme plus correct.

Compté par qui ? Vous pourriez au moins nous donner les mesures de vitesse d'abord.

 
Alexey Navoykov:

Qui compte ? Vous pourriez au moins me donner une mesure de vitesse pour commencer.

Trop d'attention pour un troll.

 
TheXpert:
Si vous suivez votre propre conseil, vous pourriez avoir au moins un aperçu de l'allocation.

Par allocation, je voulais dire allocation de mémoire.
Pas au sens littéral comme une classe.
Une fonction définie par l'utilisateur a sa propre portée.

 
Alexey Navoykov:

Qui compte ? Vous devriez au moins donner quelques mesures de vitesse pour commencer.

Sur la page précédente, fxsaber a donné les mesures.
J'ai expliqué pourquoi ça se passe comme ça.
Allouez toujours de la mémoire, de manière statique ou dynamique.

 
Sergey Dzyublik:

Vous avez peut-être ce défaut :

(non corrigé par ME5(build 2390)) ** (nouveau) Débogueur, StepInto (F11) et les points d'arrêt installés ne fonctionnent pas.

C'est possible... J'ai essayé la méthode int CCheckGroup::itemCheckState(const string item) que j'ai décrite ci-dessus. Et au début, le débogueur y va. Mais une fois qu'il se termine et que c'est tout, le débogueur ne le voit plus et aucun point d'arrêt ou "Step with enter" ne fonctionne. Eh bien, nous devrons nous contenter temporairement de Print() et Alert().

 
Roman:

Sur la page précédente, fxsaber a donné des mesures.
J'ai expliqué pourquoi c'est le cas.
Allouez toujours de la mémoire, de manière statique ou dynamique.

Quel genre de mesures ? Si vous voulez dire une grande table, seule la partie gauche est visible à l'écran, le reste est coupé, donc je ne sais pas ce qu'il y a.

Mais à en juger par le code, si cette macro est comparée

GetCurrentTick2(Tick, !i)

Je n'ai qu'un appel de fonction pour 100 itérations. Et la première macro a un appel à chaque itération. Donc ça n'a pas de sens.

1...274127422743274427452746274727482749275027512752275327542755...3184
Nouveau commentaire