Erreurs, bugs, questions - page 2532

Nouveau commentaire
 
Si la question est résolue, pouvez-vous m'aider ? Pour vous, mammouths de la programmation, c'est comme un roseau...
 
Georgiy Merts:

Bien sûr, l'accès public aux membres de la classe n'est pas bon, mais le problème principal - l'accès aux données du tableau sans copie - est résolu.

Je regarde beaucoup de vidéos sur YouTube, je suis tombé sur la chaîne d'un programmeur intelligent, et je me souviens de la phrase : " le code doit, avant tout, accomplir sa tâche ! ".

Vous ne travaillez pas sur un grand projet, n'est-ce pas ? - Vous savez pourquoi ce membre de classe est défini et vous pouvez en contrôler l'accès sans l'aide du compilateur, n'est-ce pas ? ;)

 

@Ilyas, mise à jour de la construction de mt4


code qui fonctionnait bien après la compilation et les erreurs d'exécution


 
Igor Makanu:

Je regarde beaucoup de vidéos sur YouTube, je suis tombé sur la chaîne d'un bon programmeur, et je me souviens de la phrase : "le code doit, avant tout, remplir sa tâche ! ....".

Vous ne travaillez pas sur un grand projet, n'est-ce pas ? - Vous savez pourquoi ce membre de classe est défini et vous pouvez en contrôler l'accès sans l'aide du compilateur, n'est-ce pas ? ;)

En fait, l'accès aux membres d'une classe est mieux implémenté par des méthodes et pour avoir moins de déréférencement en cours d'exécution, utilisez les méthodes inline avec les méthodes get.
 
Igor Makanu:

Je regarde beaucoup de vidéos sur YouTube, je suis tombé sur la chaîne d'un bon programmeur, et je me souviens de la phrase : "le code doit, avant tout, remplir sa tâche !".

Vous ne travaillez pas sur un grand projet, n'est-ce pas ? - Vous savez pourquoi ce membre de classe est défini et vous pouvez en contrôler l'accès sans l'aide du compilateur, n'est-ce pas ? ;)

NON.

Tout d'abord, le code doit être transparent et compréhensible, facile à maintenir. Et s'il ne remplit pas sa mission, cela sera immédiatement visible.

Mais lorsque le code est rempli de nombreux fragments avec des constructions potentiellement dangereuses qui provoquent des erreurs très subtiles et non évidentes, vous ne pouvez jamais être sûr que "le code remplit sa tâche".

Et lorsqu'on travaille sur un grand projet, on ne peut absolument pas s'en passer. Dans de nombreuses entreprises, il existe des directives officielles concernant la notation, les déclarations, ce qui peut et ne peut pas être déclaré comme actions, etc. Bien sûr, quand on travaille seul, on déclare un membre de la classe, on sait à quoi il sert et on sait comment on va l'utiliser. Sauf que tout code, aussi complexe soit-il, même réalisé par un seul programmeur, tend à modifier l'architecture. Et je ne peux personnellement pas me souvenir de quoi, où, comment et pour quoi. En même temps, je surcharge généreusement le code avec des commentaires détaillés. Et pourtant, en revenant à d'autres fragments après six mois, je passe beaucoup de temps à comprendre pourquoi ils ont été faits de cette façon et non d'une autre. Sans commentaires, je ne serais pas du tout capable de comprendre mon propre code.

Bien sûr, si vous avez la mémoire de Peter Konov, vous n'avez pas à vous soucier du partage de l'accès, rendez toutes les variables globales - et utilisez tout ce dont vous avez besoin, quand vous le voulez. Cependant, ma mémoire est bien moins bonne, et je peux déjà oublier les subtilités d'une procédure en une semaine. C'est pourquoi j'ai depuis longtemps développé un principe selon lequel, à n'importe quel endroit du code, il doit y avoir exactement ce dont j'ai besoin ici et pas une seule variable de plus. Le meilleur moyen est de tout convertir en interfaces virtuelles et de diviser autant que possible les zones de responsabilité de chaque classe (mais il faut bien sûr une certaine mesure, afin de ne pas avoir à s'occuper de ces enveloppes plus que du code utile).

Rappelons que l'absence de pointeurs sur les tableaux est justifiée par les développeurs par le souci de "prendre soin des programmeurs", afin d'éviter l'utilisation accidentelle d'un pointeur sur un tableau qui n'est plus pertinent. Eh bien, ils ont expliqué que "si vous écrivez avec des classes, vous êtes déjà suffisamment compétent pour utiliser des pointeurs, alors que les tableaux sont accessibles aux débutants, et nous ne voulons pas qu'ils aient des problèmes lorsqu'ils veulent utiliser des pointeurs vers des tableaux...". pas d'indications, c'est tout"...

 
Vladimir Simakov:
En général, il est préférable d'implémenter l'accès aux membres de la classe via des méthodes, et pour éviter le déréférencement en cours d'exécution, utilisez les méthodes inline avec get.

C'est exact. Et je suis généralement enclin à le faire. En général, j'utilise rarement les membres publics d'une classe, tous les accès se font par des méthodes en ligne. Seulement dans des cas particuliers, comme avec ces tableaux d'indicateurs, je dois utiliser les membres publics...

 
Влад:
Si le problème est résolu, pouvez-vous m'aider ? Pour vous, mammouths de la programmation, c'est comme un papillon de nuit...

Dans votre cas, organisez une boucle while() plutôt qu'une boucle for().

Vérifiez s'il y a un signe de fin de clignotement.

Mais à propos du "clignotement à fréquence variable" - quelque chose d'étrange... Je ne vois pas d'erreurs à la volée, il devrait clignoter assez souvent.

Bien que je doute que cela ait un sens de créer et de supprimer des objets graphiques, au lieu de les rendre invisibles, il semble que l'on ne puisse pas rendre un objet invisible... Il ne reste donc plus qu'à supprimer.

 
Georgiy Merts:

Bien sûr, si vous disposez d'une mémoire comme celle de Peter Konov, vous n'avez pas à vous soucier de la séparation des accès, rendez toutes les variables globales - et utilisez tout ce dont vous avez besoin, quand vous le voulez.

Je n'entraîne jamais la mémoire, je n'utilise les variables globales qu'en dernier recours, le code me semble même parfois redondant, mais les fragments de code sont portables dans un autre projet,

J'utilise généralement des noms de fonctions et de variables longs, afin de pouvoir lire ce que j'ai écrit auparavant :

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }
Un autre problème est que je n'adhère pas au style POO - je n'enveloppe pas tout dans des classes, j'utilise simultanément les styles procédural et POO dans un programme, il est plus pratique et plus rapide de former un programme à partir de blocs prêts à l'emploi, ce qui manque, je l'ajoute ou le modifie en fonction de la tâche à accomplir.
 
Vladimir Simakov:
et pour réduire le déréférencement en cours d'exécution, utilisez les méthodes inline avec les méthodes get.
L'inline est une relique, à mon avis. Le compilateur inline tout parfaitement, il n'y a donc pas besoin de surcharger le code. Et dans MQL, ce spécificateur n'est rien du tout, ajouté uniquement à des fins de compatibilité (je ne sais pas pour quoi, si on pouvait déclarer une telle macro par soi-même).
 
Georgiy Merts:

Dans votre cas, organisez une boucle while() plutôt qu'une boucle for().

Vérifiez s'il y a un signe de fin de clignotement.

Mais à propos du "clignotement à fréquence variable" - quelque chose d'étrange... Je ne vois pas d'erreurs à la volée, il devrait clignoter assez fréquemment.

Certes, je doute qu'il soit judicieux de créer et de supprimer des objets graphiques au lieu de les rendre invisibles, mais il semble que l'on ne puisse pas rendre un objet invisible... Il ne reste donc que la suppression.

Merci pour la réponse, cela fonctionne maintenant. Mais le clignotement est tout aussi chaotique, enregistré comment il se produit. Et j'ai remplacé la suppression par le changement de la couleur de l'étiquette en noir.



int i = 1;
   while(i > 0)  //true?
   {      
      if(!ObjectCreate(0,"Blink",OBJ_LABEL,0,0,0))
   {
      Print("Not Create! Error - ",GetLastError());
   }
   ObjectSetInteger(0,"Blink",OBJPROP_XDISTANCE,50+i);
   ObjectSetInteger(0,"Blink",OBJPROP_YDISTANCE,50);
   ObjectSetInteger(0,"Blink",OBJPROP_CORNER,CORNER_RIGHT_UPPER);
   ObjectSetString(0,"Blink",OBJPROP_TEXT,"Test");
   ObjectSetString(0,"Blink",OBJPROP_FONT,"Arial");
   ObjectSetInteger(0,"Blink",OBJPROP_FONTSIZE,18);
   ObjectSetDouble(0,"Blink",OBJPROP_ANGLE,0);
   ObjectSetInteger(0,"Blink",OBJPROP_ANCHOR,ANCHOR_RIGHT_UPPER);
   ObjectSetInteger(0,"Blink",OBJPROP_COLOR,Red);
   ObjectSetInteger(0,"Blink",OBJPROP_BACK,false);
   ObjectSetInteger(0,"Blink",OBJPROP_SELECTABLE,true);
   ObjectSetInteger(0,"Blink",OBJPROP_SELECTED,false);
   ObjectSetInteger(0,"Blink",OBJPROP_HIDDEN,true);
   ObjectSetInteger(0,"Blink",OBJPROP_ZORDER,0);
   
   Sleep(200);
   
   ObjectSetInteger(0,"Blink",OBJPROP_COLOR,Black);
   
   Sleep(200);
   }
1...252525262527252825292530253125322533253425352536253725382539...3184
Nouveau commentaire