Question sur la dactylographie - page 3

Nouveau commentaire
 
Ilya Malev:

L'erreur d'inadéquation des modèles devrait probablement se produire au moment de la compilation.


Mais dans la situation où il y a un objet de type tableau

Une telle erreur ne devrait pas se produire car dans le premier cas, l'appel de Array[int] est utilisé comme paramètre gauche de l'opération = et n'est pas une variable de type double, alors que dans le second cas, c'est le paramètre droit, et le paramètre gauche est une variable de type double.

Vous n'entendez pas, il ne devrait rien faire - la surcharge de type est interdite et c'est explicitement écrit dans la norme C++ (et µl comme C++ similaire - probablement aussi) :

Certain function declarations cannot be overloaded:

- Function declarations that differ only in the return type, the exception specification (18.4), or both
cannot be overloaded.

La raison probable est expliquée ci-dessus. Donc votre opérateur[] est invalide.

 
pavlick_:

Vous n'entendez pas, il ne devrait rien faire - la surcharge par type est interdite et c'est explicitement écrit dans la norme C++ :

La raison probable que j'ai donnée ci-dessus. Donc vos opérateurs[] sont invalides.

Je ne vous répondais pas sur la norme, mais sur la logique basée sur le bon sens. Votre définition de la cause "probable" n'invalide pas mes arguments. La possibilité de surcharger une opération de typage (y compris implicitement) ne contredit pas la norme que vous avez citée, car c'est l'opération de coulage vers un type particulier explicitement défini à partir du contexte qui est surchargée.

Je n'ai peut-être pas été très clair, mais j'espère que cette clarification rendra les choses plus claires.


P.S. Bien sûr, mon code fictif est en contradiction avec la norme. Mais si vous devez le déchiffrer (parce que je cherchais moi-même comment formuler la question de manière plus précise), il devrait ressembler à ceci :

class Array{

public:

Array *operator[] (int i){ id = i; return GetPointer( this ); }

double operator double(){ return data[i]; }

Array *operator=(double d){ data[id]=d; return GetPointer( this ); }

private:

double data[10];

int id;

};



int OnStart(){

  Array array;

  double d=123.456;

  array[5]=d;

  d=array[5];

}
 
Si vous préconisez l'opérateur type(), très bien. Si vous préconisez l'indentation à partir des plus, alors je suis contre (autoriser la surcharge par type de retour) pour résoudre un problème particulier (qui pourrait probablement être résolu différemment et de manière plus belle - d'une manière ou d'une autre, je n'ai jamais eu l'occasion de le faire comme dans le premier message).
 
pavlick_:
Si vous préconisez l'opérateur type(), très bien. Si vous préconisez l'indentation à partir des plus, alors je suis contre (autoriser la surcharge par type de retour) pour résoudre un problème particulier (qui peut sûrement être résolu différemment et plus joliment - d'une manière ou d'une autre, je n'ai jamais été tordu de la sorte comme dans le premier post).

Oui. En fin de compte, je suis tout à fait favorable à l'introduction de l'opérateur de frappe. Parce que cela résout exactement le problème que j'ai énoncé dans le message initial, mais d'une manière plus "conventionnelle" (conforme aux normes, et probablement plus correcte en général).

 
Ilya Malev:

P.S. Bien sûr, mon code inventé est contraire à la norme.

Pourquoi cela contredit-il la norme, c'est parfaitement valable dans les plus. Et il n'y a pas du tout de quais à McLaren.
 
pavlick_:
Pourquoi est-ce contradictoire, en plus c'est tout à fait valable. Et à MQL, il n'y a pas de quais du tout.

Parce qu'à l'origine il y avait deux fonctions operator[] identiques avec un type de retour différent (je l'ai corrigé dans la deuxième version). Ceci est interdit par la norme. Mais citer des types (y compris implicitement) n'est pas interdit, ils n'ont juste pas encore eu le temps de l'implémenter. Compte tenu du rythme impressionnant de développement de mql5, je suis sûr qu'il sera implémenté tôt ou tard. Surtout si quelqu'un d'autre que moi y prête attention sur le forum...

 
Ilya Malev:

Parce qu'il y avait deux fonctions operator[] identiques avec un type de retour différent. Ceci est interdit par la norme. Il n'est pas interdit de taper (même implicitement), ils n'ont juste pas encore eu le temps de l'implémenter. Compte tenu de la grande vitesse de développement de mql5, je suis sûr qu'il sera mis en œuvre tôt ou tard. Surtout si quelqu'un d'autre que moi y prête attention sur le forum...

Je veux dire le dernier code - c'est bien.

 
pavlick_:

Je veux dire le dernier code - c'est bon.

C'est OK, mais ça ne fonctionne pas encore dans mql5. Suivons et espérons des innovations dans mql5. C'est cette incapacité à implémenter correctement un objet tableau, en raison de l'impossibilité de gérer un type d'utilisateur de la même manière qu'avec un tableau ordinaire, qui me dérange personnellement depuis longtemps. Lorsque vous créez votre propre tableau, il s'avère être défectueux dès le départ, ne possédant pas les mêmes propriétés d'utilisation que les tableaux intégrés.

 
Ilya Malev:

C'est OK, mais ça ne fonctionne pas encore dans mql5. Suivons et espérons des innovations dans mql5. C'est cette incapacité à implémenter correctement un objet tableau, en raison de l'impossibilité de gérer un type d'utilisateur de la même manière qu'avec un tableau ordinaire, qui me dérange personnellement depuis longtemps. Lorsque vous fabriquez votre propre tableau, il s'avère initialement défectueux, n'ayant pas la même facilité d'utilisation qu'un tableau intégré.

Bon, je ne m'attends pas à de grands miracles, le langage n'est plus vraiment développé, je doute qu'ils ajoutent un opérateur fantôme. Ici, je suis spécifiquement stressé par l'impossibilité de procéder de cette façon :

class Q {};

Q q;
// что то делаем и решаем переинициализировать q
q = Q();  // ошибка, нужно извратиться:

Q temp;
q = temp;

mais c'est inutile de le dire, je pense.

 
pavlick_:

Bon, je n'attends pas de grands miracles, le langage n'est plus vraiment développé, je doute qu'ils ajoutent un opérateur fantôme. Ce qui me dérange en particulier, c'est l'impossibilité de procéder de cette manière :

Mais il est inutile d'en parler, je pense.

Le problème n'est pas très clair. L'initialisation de l'objet ne pourrait-elle pas être implémentée dans une méthode séparée comme Init(), peut-être même dans une méthode virtuelle ?

12345678910
Nouveau commentaire
Raison: