Questions sur la POO dans MQL5 - page 80

Nouveau commentaire
 
Vladimir Simakov:

Je suis d'accord))) C'est moi du côté positif.))

J'ai vu comment tout cela se déroule pendant que j'écris.

C'est-à-dire pas sur le côté positif, mais sur le museau de la version précédente, cela fonctionnera, n'est-ce pas ?

JSONObject * CActor::getJSONObject(const string json)const
{
   JSONParser parser;
   JSONValue  *jv = parser.parse(json);
   if (jv != NULL && jv.isObject() && (EACTOR_TYPE)(((JSONObject *)jv).getInt("ActorType")) == ActorType) return(jv);
   Print(__FUNCTION__ + "parser error, json = ",json);
   delete jv;
   return(NULL);
}
 
Igor Makanu:

pendant que j'écrivais ça, tout s'est inversé.

C'est-à-dire pas du côté positif, mais du côté de la bouche, l'option précédente fonctionnera, n'est-ce pas ?

Cette option - oui))

Seulement il a deux dynamic_casts implicites
 
Vladimir Simakov:

1) Mis en évidence. Vérifiez seulement sur la ligne suivante))) Dans l'exemple du créateur de la librairie, c'est exactement le contraire, d'abord vérifier, ensuite couler)
2) si JSONObject a un héritier, pourquoi devrait-il tomber ?

1) En fait, un seul et même code est discuté depuis plusieurs jours dans ce fil de discussion :ici, ici et ici.
Le fait que vous ayez trouvé un problème dans l'un des exemples d'utilisation de la bibliothèque par les utilisateurs - bien joué, merci.
Cependant, vous avez fait état d'un problème dans la logique d'utilisation de la bibliothèque dans son ensemble, mais il s'avère en fait que le problème concerne un exemple spécifique.

2) Où avez-vous vu l'affirmation selon laquelle quelque chose devrait baisser ?
Non, cela pourrait être bien pire - le code fonctionnera bien, mais produira des résultats incorrects.

 
Sergey Dzyublik:

2) Où avez-vous vu l'affirmation selon laquelle quelque chose devrait baisser ?
Non, cela pourrait être bien pire - le code fonctionnera bien, mais produira des résultats incorrects.

IMHO bien sûr, mais si dans la librairie, lorsque je me réfère à un objet par un pointeur vers une classe de base, j'obtiens un comportement non défini, cela devrait être reflété dans le manuel de la librairie (y est-il ?), mais cela ne devrait pas l'être ;)

 
Sergey Dzyublik:

Non, cela pourrait être bien pire - le code fonctionnera bien, mais produira des résultats incorrects.

Peu probable, mon exemple est une méthode d'une classe de base, JSONObject * est le résultat de l'exécution, c'est un pointeur vers le parseur, et le parseur json lui-même dans la méthode descendante se produit avec le pointeur reçu, qui devait être "cloué" dans mes questions précédemment mentionnées.

il y a beaucoup de vérifications, dans l'exemple proposé il y a 3 pcs et dans la classe dérivée chaque appel des méthodes getInt(), getDouble() se produit avec des vérifications

 
Vladimir Simakov:

IMHO bien sûr, mais si dans la librairie, lorsque je fais référence à un objet par un pointeur vers une classe de base, j'obtiens un comportement non défini, cela devrait être reflété dans le manuel de la librairie (existe-t-il ?), mais ça ne devrait pas être comme ça)

Encore une fois, qu'est-ce que les pointeurs et les non-pointeurs, les manuels, etc. ont à voir avec cela ? ?
Dans votre exemple, une partie de la LOGIQUE sera supprimée de la fonction, à savoir la vérification dejv.isObject()
. Cette LOGIQUE a été remplacée par une vérification via dynamic_cast.
Pour la version actuelle de la bibliothèque tout est ok, mais, théoriquement, si dans la prochaine version il y aura une nouvelle classe qui utiliseJSONObject comme base, pas le fait que votre exemple peut fonctionner avec elle correctement.

 
Sergey Dzyublik:

Encore une fois, qu'est-ce que les pointeurs et les non-pointeurs, les manuels, etc. ont à voir avec cela ? ?
Dans votre exemple, une partie de la LOGIQUE sera supprimée de la fonction, à savoir la vérification dejv.isObject()
. Cette LOGIQUE a été remplacée par une vérification via dynamic_cast.
Pour la version actuelle de la bibliothèque tout est ok, mais, théoriquement, si dans la prochaine version il y aura une nouvelle classe qui utiliseJSONObject comme base, pas le fait que votre exemple fonctionnera avec elle correctement.

Ainsi, une autre version ne pourra pas non plus fonctionner correctement avec elle).

 
Andrei Trukhanovich:
Il n'y a pas d'UB, le cast mql inclut aussi le dynamic_cast. Tout tombera en cas de mauvais pointeur.

C'est le cas ? Dans le cas de dynamic_cast, rien ne tombera si vous vérifiez le résultat pour NULL. Avec un lancer normal, il tombera immédiatement. Ou est-ce que je me suis trompé ?

 
Vladimir Simakov:

IMHO bien sûr, mais si dans la librairie, lorsque je me réfère à un objet par un pointeur vers une classe de base, j'obtiens un comportement non défini, alors cela devrait être reflété dans le manuel de la librairie (y est-il ?), mais ça ne devrait pas être comme ça)

Il devrait y avoir une exception chez les pros. Et une lettre aux auteurs, car une exception n'est pas une bonne chose, c'est juste un bouchon. Il n'y a pas de telle chose dans mql, donc les classes sont créées en pensant à l'avenir, avec un protocole complet.

A propos du json discuté - vous avez seulement 2 options, soit suivre le style et les solutions de l'auteur, soit faire votre propre fork. Le reste est mauvais. 😉

 
Vladimir Simakov:

Et cela en vaut la peine)))) Ne lancez JAMAIS directement de la base au descendant - c'est un UB (UNDEFINED BEHAVIOR).

Dans les plus, il est généralement dangereux de lancer des références (qu'elles soient ascendantes ou descendantes) par le biais de l'opérateur gimme standard, qui nous est familier et pratique.

1...737475767778798081828384858687...96
Nouveau commentaire