Bibliothèque de classes génériques - bogues, description, questions, caractéristiques d'utilisation et suggestions - page 20
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
1. Éliminez les comportements ambigus :
Si nous passons "INT_MAX - 10" comme paramètre à CPrimeGenerator::ExpandPrime, le résultat "INT_MAX" sera renvoyé.
Si nous passons "INT_MAX - 10" comme paramètre à CPrimeGenerator::GetPrime, le même résultat sera renvoyé : "INT_MAX - 10".
Dans les deux cas, la valeur renvoyée n'est pas un nombre premier, ce qui induit l'utilisateur en erreur.
Sur le premier point :
Il n'y a aucune ambiguïté ici.
La méthode GetPrime devrait renvoyer le nombre premier le plus proche, mais sur l'intervalle de INT_MAX - 10 à INT_MAX, il n'y en a pas, c'est pourquoi INT_MAX - 10 est renvoyé.
La méthode ExpandPrime double d'abord la valeur d'entrée et la méthode GetPrime est appelée à partir du nombre reçu.
En outre, ExpandPrime a une vérification pour le dépassement de INT_MAX :
À mon avis, la logique qui sous-tend le comportement de ces méthodes est absolument sans ambiguïté et correcte.
En ce qui concerne les deuxième et troisième points :
Les changements que vous suggérez ne sont pertinents, pour la plupart, que pour les problèmes de bord, lorsque les tailles de CHashMap sont très grandes. Cependant, il n'y a aucune garantie qu'ils auront un impact positif sur les performances. Des études distinctes doivent donc être réalisées pour déterminer la justesse des changements que vous suggérez.
Il n'y a aucune ambiguïté ici.
La méthode GetPrime devrait renvoyer le nombre premier le plus proche, mais il n'y en a aucun entre INT_MAX - 10 et INT_MAX, donc INT_MAX - 10 est renvoyé.
La méthode ExpandPrime double d'abord la valeur d'entrée et la méthode GetPrime est appelée à partir du nombre reçu.
En outre, ExpandPrime a une vérification pour le dépassement de INT_MAX :
La logique du comportement de ces méthodes est absolument sans ambiguïté et correcte.
1. Les fonctions peuvent renvoyer des nombres inconnus au lieu de nombres premiers.
La façon dont l'utilisateur utilise ces données est son problème, peut-être qu'il les intègre dans le long et les transmet ensuite aux fonctions de supercalcul, peu importe.
Le fait est que nous pouvons retourner quelque chose de différent de ce qui est déclaré et attendu des fonctions par défaut.
2. Comment vérifier que l'appel de la fonction a retourné un nombre premier et non autre chose ?
Vous ne pouvez pas simplement le comparer à INT_MAX.
Vous devez le comparer avec le dernier nombre premier disponible inférieur à INT_MAX.
Chaque fois que l'on compare le résultat des appels de ces fonctions à un nombre magique pour s'assurer que tout va bien, je trouve cela absurde.
1. Les fonctions peuvent ne pas renvoyer des nombres premiers, mais des nombres obscurs.
La façon dont l'utilisateur utilise ces données est son problème. Il peut les convertir en données longues et les transmettre ensuite à des fonctions de supercalcul, peu importe.
Le fait est que nous pouvons retourner quelque chose de différent de ce qui est déclaré et attendu des fonctions par défaut.
2. Comment vérifier que l'appel de la fonction a retourné un nombre premier et non autre chose ?
Vous ne pouvez pas simplement le comparer à INT_MAX.
Vous devez le comparer avec le dernier nombre premier disponible inférieur à INT_MAX.
Comparer le résultat de chaque appel de ces fonctions avec un nombre magique à chaque fois pour s'assurer que tout est correct, me semble absurde.
1. Votre cas d'obtention d'un nombre non simple à l'aide de la méthode GetPrime est le seul que j'ai rencontré jusqu'à présent. Cet incident sera corrigé en modifiant la vérification lors de la génération de nombres premiers :
2. La méthode CPrimeGenerator::IsPrime est utilisée pour vérifier le nombre par souci de simplicité.
J'ai essayé de passer de mon ArrayList au vôtre, qui est dans Generic/ArrayList.mqh
ME ne donne rien après ".".
Comment obtenir la valeur ? Get() et [] sont absents de la classe.
Et cela ne prend pas en compte le fait qu'il pourrait y avoir un tableau de pointeurs.
Et qui crée cette bibliothèque ?
Voici ma version d'ArrayList de Java :
Pour que les collections Generic fonctionnent correctement avec les objets de classe, ces classes doivent implémenter l'interface IEqualityComparable dans laquelle les méthodes Equals et HashCode sont définies. Cela signifie que l'utilisateur doit définir les méthodes de calcul des codes de hachage et c'est la seule option à ce jour, car il est impossible de mettre en œuvre ces méthodes automatiquement, comme cela a été fait dans .Net, par exemple, au moyen de MQL5.
Alors pourquoi votre modèle fonctionne-t-il avec n'importe quel type, trompant le programmeur ? Si seules les classes héritées de IEqualityComparable fonctionnent correctement, alors nous devrions désactiver le travail avec d'autres types au niveau du compilateur.
Laissez-moi vous rappeler ce code :
Je pense que cette fonction devrait être remplacée par celle-ci :
Si seules les classes héritées de IEqualityComparable fonctionnent correctement, alors vous devriez interdire le travail avec d'autres types au niveau du compilateur.
Il ne sera pas commode de travailler avec ce type. Les surcharges GetHashCode pour les types standard montrent l'interface d'obtention du code de hachage.
Ce qui est ennuyeux, c'est qu'il est absent.
C'est-à-dire pour les objets bummer maintenant.
Ce serait gênant de travailler avec ça. Les surcharges GetHashCode pour les types standard montrent l'interface pour obtenir le code de hachage.
Qu'est-ce qui est pratique maintenant ? Le fait de passer un enum ou un pointeur d'une classe qui ne supporte pas l'interface dans cette fonction, vous obtenez juste le nom de la classe ? ) Et le plus important, le code fonctionne et compile comme si tout était normal.
Qu'est-ce qui est pratique maintenant ? Que passer un enum ou un pointeur d'une classe qui ne supporte pas l'interface dans cette fonction, vous obtenez juste le nom de la classe ? Awesome hash ) Et le plus important, le code fonctionne, compile comme si tout était normal. Ce n'est pas le cas.
Oui, ils ont fait une bêtise. Ils ont inconsidérément copié et collé à partir de NetFramework alors qu'il est évident que sans prise en charge des interfaces au niveau du langage, il ne peut pas fonctionner de manière adéquate. Je me souviens du niveau des codes MQ il y a 6-7 ans et maintenant c'est nul comparé à cette époque.
Le fait qu'en passant un enum ou un pointeur d'une classe qui ne supporte pas l'interface dans cette fonction, vous obtenez juste le nom de la classe ? Joli hash ) Et le plus important, le code fonctionne et compile comme si tout était ok. Ce n'est pas le cas.
Je suis d'accord, il vaut mieux obtenir une erreur de compilation tout de suite que de s'occuper de la longue question de savoir pourquoi ça ne fonctionne pas.
Pour être honnête, je ne vois même pas pourquoi ils ont collé une interface à cet endroit. Après tout, il suffit de surcharger GetHashCode pour le type requis et non de commencer à créer IEqualityComparable.