![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
peu importe ce qu'il faut initialiser, même int - n'importe quel nombre pour appeler ce constructeur
et j'ai choisi 0.0 pour éviter les fautes d'impression - n'importe quel chiffre, c'est-à-dire 0.0. Il est plus difficile d'écrire et de faire des fautes d'impression que 123.
(double)0
mais pas comme ça non plus)))) vient de regarder le code normalement, il y a encore un moyen de le regarder anormalement))(double)0
pas de
Je n'écris que 0.0 - aucun autre nombre n'est attendu - il n'y a même pas de variable dans le constructeur.
en général, comme un style d'auteur à la mode, probablement pas le meilleur
le point n'est pas le x) mais qu'il peut y avoir un flotteur sur le récepteur, et il n'est pas fiable de spécifier 0.0 non plus
0.0 est un double sans ambiguïté pour le compilateur, le flottant sera 0.f
crédit)
Puisque la section "questions sur les plus de 50 ans" est ouverte, permettez-moi d'intervenir sur le sujet des plâtres.
- Quels sont les moyens d'améliorer le code en termes de tolérance aux pannes ou de non-redondance ?
- La vérification deCheckPointer()!=POINTER_INVALID est-elle nécessaire ? Ou absolument pas nécessaire ? Expliquez pourquoi.
- à non-const, de sorte qu'il est possible d'appeler des méthodes non-const. Peut-on appeler des méthodes non constantes directement dans la méthode Compare, c'est-à-dire se débarrasser du surlignage jaune const ?
Puisque la section "questions sur les plus de 50 ans" est ouverte, permettez-moi d'intervenir sur le sujet des plâtres.
- Quels sont les moyens d'améliorer le code en termes de tolérance aux pannes ou de non-redondance ?
- La vérification de CheckPointer()!=POINTER_INVALID est-elle nécessaire ? Ou absolument pas nécessaire ? Expliquez pourquoi.
- à non-const, de sorte qu'il est possible d'appeler des méthodes non-const. Peut-on appeler des méthodes non constantes directement dans la méthode Compare, c'est-à-dire se débarrasser desconstantes surlignées en jaune ?
C'est un peu la même chose que la tienne, mais avec moins de lettres. C'est une question de goût, qui aime mieux cela, mais j'ai supprimé la variable supplémentaire (le compilateur la supprimerait probablement aussi dans le cadre de l'optimisation).
En ce qui concerne ma vérification du nœud. Il doit être remplacé par CheckPointer(node)==POINTER_INVALID, mais c'est une surcharge - un appel de fonction. Même si c'est inlined, il y a au moins déréférencement et vérification du drapeau d'état. Si vous n'avez écrit qu'une bibliothèque ou un programme concret qui utilisera les méthodes de comparaison, il est préférable d'utiliser !node et on code pour surveiller les pointeurs invalides. Si vous êtes trop paresseux pour faire attention aux pointeurs ou si c'est une bibliothèque pour les outsiders, seulement CheckPointer(node)==POINTER_INVALID.
Si vous retirez le spécificateur const que vous avez mis en évidence, vous ne pouvez pas appeler ces méthodes à partir d'un objet constant.
UPD : la vérification en surbrillance peut être supprimée, car elle se trouve dans les méthodes appelées.
Puisque la section "questions sur les plus de 50 ans" est ouverte, permettez-moi d'intervenir sur le sujet des plâtres.
- Quels sont les moyens d'améliorer le code en termes de tolérance aux pannes ou de non-redondance ?
- La vérification de CheckPointer()!=POINTER_INVALID est-elle nécessaire ? Ou absolument pas nécessaire ? Expliquez pourquoi.
- à non-const, de sorte qu'il est possible d'appeler des méthodes non-const. Est-il possible d'appeler une méthode non-const directement dans la méthode Compare, c'est-à-dire de se débarrasser du surlignage jaune const ?
L'idée est d'écrire deux méthodes de la même fonction avec et sans le corps de la constante - pour ne pas dire plus - cela n'en vaut pas la peine)))).
Mais la probabilité de rencontrer deux méthodes est proche de zéro..... Parce que la possibilité de l'existence deCChartObjectRectangle::Price - sans const dans le corps - je pense que c'est peu probable.
L'appel de cette fonction depuis l'extérieur n'a aucun effet. C'est-à-dire que le const ne fonctionne qu'avec les fonctions internes et s'assure que rien n'a été écrit dans la mémoire de l'objet (n'a pas changé la valeur de la variable). En d'autres termes, vous ne pouvez pas appeler Set(a) pendant const... Souvent, dans une certaine confusion, pour s'assurer que cette fonction n'écrase rien, on peut rapidement arranger ces constantes (bien que ce soit probablement ma suppression).
Considérez que les constantes devraient être poussées un peu partout sans obtenir)))) pour faciliter la vérification ultérieure de quelque chose.
CheckPointer()!=POINTER_INVALID doit-il être vérifié ?
Et pourquoi pas.... en faire un bool Check(<template> &T) { retun CheckPointer(T)!=POINTER_INVALID } Le compilateur doit le rendre aussi simple que possible. Et ce sera encore mieux.
C'est plus rapide.
Eh bien, je n'ai pas beaucoup changé.
C'est tout votre code.
Il semble que ce soit le même que le vôtre, mais avec moins de lettres. C'est donc une question de goût, mais j'ai supprimé la variable supplémentaire (très probablement, le compilateur l'aurait supprimée dans le cadre de l'optimisation).
En ce qui concerne ma vérification du nœud. Il doit être remplacé par CheckPointer(node)==POINTER_INVALID, mais c'est une surcharge - un appel de fonction. Même si c'est inlined, il y a au moins déréférencement et vérification du drapeau d'état. Si vous n'avez écrit qu'une bibliothèque ou un programme concret qui utilisera les méthodes de comparaison, il est préférable d'utiliser !node et on code pour surveiller les pointeurs invalides. Si vous êtes trop paresseux pour faire attention aux pointeurs ou si c'est une bibliothèque pour les outsiders, seulement CheckPointer(node)==POINTER_INVALID.
Si vous supprimez le spécificateur const, vous ne pouvez pas appeler ces méthodes à partir d'un objet constant.
il m'a fallu beaucoup de temps pour ouvrir l'onglet
Je suppose que 4 ans d'université n'ont pas ajouté grand chose à mes connaissances (l'explication est à la traîne dans la poubelle).
la variante sans la constitution puisque la classe de base n'a pas de référence aux paramètres d'entrée fonctionnera aussi correctement, bien que ce ne soit pas un style très intelligent
Egalement une variante du même code.
C'est le même que celui avec les constantes.