Erreurs, bugs, questions - page 2521

Nouveau commentaire
 
Alexey Navoykov:

La première affectation ne fonctionne que dans MQL. J'aimerais qu'ils annulent enfin ce malentendu. Je n'ai aucun problème avec le second.

C'est bizarre. Je pensais que le premier devait fonctionner et que le second ne fonctionnait pas.

 
fxsaber:

C'est bizarre. Je pensais que le premier devait fonctionner et que le second ne fonctionnait pas.

Apparemment, les développeurs de MQL ne comprennent pas non plus l'essence de l'affectation. Car cela fait longtemps que je leur parle de ce problème, mais je me heurte à un mur.

L'essence de l'affectation est que l'objet est affecté à un objet équivalent. Cela signifie que l'objet de droite est d'abord casté dans le type de l'objet de gauche de manière implicite et qu'ensuite seulement, l'affectation (copie) a lieu. Et dans le premier cas, un tel casting (A->B) est certainement impossible.En C++, il y aura une erreur, mais en MQL, l'objet de gauche est casté en objet de droite et A::operator=(A&) est exécuté, remplaçant seulement une partie de l'objet b. Est-ce une affectation ?

Imaginez que vous assignez int à long, mais que seuls les quatre premiers octets sont remplacés et que le reste est laissé intact. C'est la même chose ici.

 
Alexey Navoykov:

Imaginez que vous assignez un int à un long, mais que seuls les quatre premiers octets sont remplacés, et que le reste n'est pas touché. C'est la même chose ici.

Donc c'est pratique, je suppose. Dans le cadre des structures, bien sûr.

 
fxsaber:

Donc c'est pratique, il semble. Dans le cadre des structures, bien sûr.

Il peut sauvegarder des caractères dans une chaîne, mais il est une source d'erreurs aléatoires et complique/déforme la compréhension du code. Comme je l'ai déjà dit plus haut, le signe égal signifie clairement et sans ambiguïté que l'objetentier est modifié. C'est pourquoi l'opérateur n'est pas utilisé comme prévu dans ce cas. Si vous voulez un tel comportement non standard, vous devriez surcharger l'opérateur à cette fin.

p.s. La seule exception est si la classe B n'a pas de champs propres, c'est-à-dire qu'elle est exactement la même que la classe A (totalement équivalente à elle), alors il n'y a aucune raison d'empêcher cette affectation, bien que cela ne fonctionne pas en C++ de toute façon, mais en MQL vous pouvez l'autoriser.

 
Slava:

Dans le fichier opt, dans le chunk où tous les paramètres d'entrée sont prescrits, la valeur des paramètres optimisés (définis via les champs size et offset) ne contient pas Value (comme sans optimisation), mais Start.

Il serait logique d'y avoir Value.

 
Alexey Navoykov:

Eh bien, il semble que les développeurs MQL ne comprennent pas non plus l'essence de l'affectation. Car cela fait longtemps que je leur parle de ce problème, mais je me heurte à un mur.

L'essence de l'affectation est que l'objet est affecté à un objet équivalent. En d'autres termes, du même type.

L'essence des opérations pour les types d'utilisateurs n'est pas définie au préalable. Et seul leur ordre est défini, qui consiste dans ce cas à appeler l'opérateur approprié=.

En MQL, contrairement au C++, operator= est hérité, donc b = a ; est équivalent à appeler A::operator=(const A&) ;

En général, il n'y a pas de contradiction ici. Dans le cas particulier de l'attribution d'un objet équivalent, il existe une certaine incohérence des entités, mais pas plus que cela.

 
A100:

En MQL, contrairement à C++, operator= est hérité, donc b = a ; est équivalent à appeler b.operator=(const A&) ;

Eh bien, oui, c'est le problème. Mais la différence d'écriture ne joue pas de rôle ici. En C++, cela ne compilera pas dans les deux cas.

En général, il n'y a pas de contradiction ici. Dans le cas particulier de l'affectation d'un objet équivalent, il y a une certaine incohérence des entités

Il y aura une contradiction avec le C++ au moins. Si cela compile, cela signifie que l'opérande de droite est implicitement converti en l'opérande de gauche et qu'ensuite une substitution complète de l'objet a lieu, comme cela devrait logiquement fonctionner. J'ai donné un exemple avec int->long. Et la substitution d'une partie de l'intérieur d'un objet n'est pas une affectation. Il y a donc une contradiction et une incohérence tout en un.

p.s. Bien que nous puissions également surcharger l'opérateur B::operator=(A&), je suppose qu'un programmeur sensé remplacerait l'objet B complètement, et non partiellement, puisque c'est l'essence même de l'affectation.

Si l'on veut une orthographe concise, on peut créer un autre opérateur pour cela : &= ou |= par exemple. Au moins, ils ne sont pas utilisés couramment, donc il n'y a pas de confusion.

 
Alexey Navoykov:

..........

Une contradiction serait au moins avec C++. ......

..........

Qu'est-ce qui vous fait penser que MQL doit être totalement équivalent à C++ ?

C-like ne signifie pas équivalent !

MQL est développé pour des tâches précises et n'est pas obligé de copier complètement le langage sur la base duquel il a été créé.

Allez-vous cesser de vous indigner ?

Mais en Pascal, vous pouvez .........

En assembleur, vous pouvez aller à ......

Et en Java ....

Et en BASIC ....

Vous pratiquez la comparaison des langues ici ?

=======

P.S. Ce n'est pas seulement toi...

 
Сергей Таболин:

Qu'est-ce qui vous fait penser que MQL devrait être entièrement compatible avec C++ ?

...

Vous pratiquez la comparaison des langues ici ?

Je répondais à une phrase spécifique. Calme-toi. Prends de la valériane et va te coucher. Ce n'est pas bon pour toi de t'inquiéter. ...Certaines personnes s'enflamment au mot "C++".

 

Je demande de l'aide sur WinAPI. Il faut pouvoir effectuer ces deux actions dans MT5.

Appelez le menu affiché et sélectionnez pour sauvegarder le rapport.


Appelez le menu affiché et sélectionnez le chargement d'un fichier set.


Dans MT4, ce genre de chose est très facile. Dans MT5, ce n'est pas le cas.

C'est-à-dire qu'il suffit d'ouvrir le menu et de sélectionner une option appropriée. Mais elle ne peut pas le faire.


On dirait que ça devrait l'être.

1...251425152516251725182519252025212522252325242525252625272528...3184
Nouveau commentaire