MQL5 Le compilateur ne fait pas la distinction entre une classe et un pointeur vers celle-ci - page 11

Nouveau commentaire
 
Ilya Malev:

Celui-là : (* ) n'est pas nécessaire ici.

* est nécessaire dans le µl uniquement lorsque les opérations =, ==, !=, !& ou || sont appliquées directement au * pointeur.

C'est exactement ce dont vous avez besoin, IMHO, pour ne pas oublier ce à quoi vous avez affaire (un objet ou un pointeur sur celui-ci).

Ilya Malev:

(Si vous voulez le supprimer à nouveau et faire comme s'il n'avait jamais existé)))

Donc, oui. La poursuite du développement des pointeurs conduira à un clone complet du C++.

Peut-être iront-ils dans la direction de C# où le "code géré" n'a pas de pointeurs mais tout a un objet, même les types courants bool int double, etc.

 
Ilya Malev:

Et aussi, d'ailleurs, il se pourrait bien que puisque tous les canaux officiels (forum, aide, documentation) sont silencieux au sujet de l'opérateur *, peut-être que les admins pensent à le supprimer à nouveau, et à faire comme s'il n'avait jamais existé)). Il est donc dangereux de compter sur son utilisation en général pour le moment.

Ce silence est probablement dû au fait que 99,9 % des utilisateurs ne se soucient pas de tout cela. Pourquoi embêter leur cerveau avec des informations inutiles ? Et ceux qui en avaient besoin, l'ont demandé et l'ont obtenu.

Vous ne vous êtes pas non plus soucié de cette fonctionnalité jusqu'à maintenant, n'est-ce pas ? Et maintenant vous commencez désespérément à trouver des excuses pour expliquer pourquoi vous n'étiez pas au courant ;) Quelle différence cela fait-il de savoir quand elle a été introduite : immédiatement ou après des mois ? Vous ne l'auriez toujours pas su si je ne vous l'avais pas dit ;)

 

Hmmm... Peut-être y a-t-il aussi des pointeurs vers le tableau ? Je vais devoir vérifier... Ils me manquent tellement...

 
Georgiy Merts:

Hmmm... Peut-être y a-t-il aussi des pointeurs vers le tableau ? Je vais devoir vérifier... Ils me manquent tellement...

Non. Vous devez mettre les tableaux dans les classes, ils ont des pointeurs.

 
Ilya Baranov:

Non. Vous devez mettre les tableaux dans des classes, ils ont des pointeurs vers eux.

Oui, hélas.

En fait, les classes dérivées de CArray sont très pratiques pour moi. La seule chose pour laquelle je veux des pointeurs sur des tableaux, ce sont les indicateurs, ils passent des références à des tableaux, et je dois "glisser" ces références à travers toute la hiérarchie des objets, ce qui est très peu pratique...

J'ai suggéré une fois de faire des pointeurs vers des tableaux, ou de faire une fonction d'indicateur qui utiliserait des pointeurs vers des tableaux de la Standard Library, plutôt que des liens vers des tableaux, mais hélas, j'ai été rejeté au motif que "si nous autorisons les pointeurs vers les tableaux, il sera possible d'utiliser des tableaux non initialisés", bien que les développeurs n'aient pas de telles craintes avec les objets... Ouais, eh bien, je vais laisser ça à leur conscience.

 
Georgiy Merts:

2. le MQL n'a pas à supprimer ce qu'il n'a pas sélectionné. Je n'aime pas la pratique du "collecteur d'ordures" en C#, lorsque les objets sont supprimés non pas quand je le veux, mais quand le collecteur le veut.

Le sélecteur C# ne supprimera jamais un objet vivant ou un pointeur. Son but est d'enlever les déchets du tas et parfois de le défragmenter.

 
Alexey Volchanskiy:

Jamais un assembleur C# ne supprimera un objet vivant ou un pointeur. Son but est de retirer les déchets de cadavres du tas et parfois de le défragmenter.

Je ne dis pas que le collecteur d'ordures va supprimer un objet vivant ou un pointeur. Ce que je dis, c'est qu'il le supprimera quand il le voudra. Et cela, à mon avis, n'est pas bon.

Je peux travailler avec ou sans suppression. Et je peux même faire des smartpoints... Néanmoins, je pense que la suppression des objets doit être possible et que la personne qui l'a créé doit supprimer l'objet.

C'est le genre de vieux de la vieille que je suis.

 
SemenTalonov:

Ils iront probablement dans la direction de C# où le "code géré" n'a pas de pointeurs et où tout a un objet, même les types simples bool int double, etc.

Oui, mais ils laissent toujours la possibilité de travailler avec des pointeurs dans du code non géré. Il est vrai qu'un tel code a des restrictions de distribution.

 
Georgiy Merts:

Je ne dis pas que le collecteur d'ordures va supprimer un objet vivant ou un pointeur. Ce que je dis, c'est qu'il le supprimera quand il le voudra. Et cela, à mon avis, n'est pas bon.

Je peux travailler avec ou sans suppression. Et je peux même faire des smartpoints... Mais, néanmoins, je pense que les objets devraient être supprimés, et que celui qui les a créés devrait les supprimer.

C'est le genre de vieux de la vieille que je suis.

Georges, tu veux bien donner un exemple, je ne te comprends pas. C'est ce que vous voulez dire ? Je suppose que vous pouvez faire des points intelligents vous-même.

bool first = false;

int Foo()
{
  int i;
  if(!first)
  {
     first = true; 
     i = 123;
  }
  return i;   
}

// И ты будешь надеятся, что i сохранит свое значение между сотней вызовов Foo? Может да (очень редко, если Foo вызывается 100 раз подряд), а может и нет.
 
Alexey Volchanskiy:

Georges, tu veux bien me donner un exemple, je ne te comprends pas. C'est ce que vous voulez dire ? Il est probablement possible de fabriquer soi-même des smartpoints.

Non. Il est clair que dans ce cas, la variable doit être supprimée à la sortie du bloc.

Je parle d'objets créés par de nouveaux :

CMyObj* pmoObject  = new CMyObject;

La norme C# spécifie :"Les objets de type valeur, comme les structures, et les objets de type référence, comme les classes, sont tous deux détruits automatiquement, mais les objets de type valeur sont détruits lorsque le contexte qui les contient est détruit, tandis que les objets de type référence sont détruits par le collecteur de déchets indéfiniment après la suppression de la dernière référence à ces objets."

Ici, je n'aime pas ce "temps indéfini". J'admets même que le collecteur d'ordures peut supprimer un objet beaucoup plus efficacement que moi, en supprimant l'objet dans le destructeur de la classe qui l'a créé.

1...45678910111213
Nouveau commentaire
Raison: