Questions sur la POO (programmation orientée objet) - page 8

Nouveau commentaire
 
C-4:
Typeid() n'existe malheureusement pas, et la force des templates réside dans l'identification statique. Des tâches différentes sont résolues par des méthodes différentes et dire qu'une méthode est mauvaise et l'autre bonne est une supposition aggravante.

J'ai eu un cas où une identification dynamique était nécessaire. Toutes les solutions étaient très encombrantes, à l'exception du type universel. Réalisé par une classe implémentant un type universel.

Mais j'ai eu des problèmes, aussi. Quelque chose a changé dans STL (string) depuis VS 2012 et depuis lors, il ne compile plus. Je n'ai pas encore réglé le problème.

 
Pavlick:

Huh, pas des pointeurs, mais des rires sur un bâton.


La page du deuxième lien de mon post dit :

Dans MQL4, vous pouvez créer dynamiquement des objets de type complexe. Pour ce faire, on utilise l'opérateur new, qui renvoie le descripteur de l'objet créé.

Le descripteur a une taille de 8 octets. Syntaxiquement, les descripteurs d'objets dans MQL4 sont similaires aux pointeurs en C++.

Exemples :

MyObject* hobject= new MyObject();

Encore une fois, contrairement au C++, la variable hobject de l'exemple ci-dessus n'est pas un pointeur vers la mémoire, mais un descripteur d'objet.


 
EverAlex:

La page du deuxième lien de mon post dit :

Dans MQL4, vous pouvez créer dynamiquement des objets de type complexe. Cela se fait à l'aide de l'opérateur new, qui renvoie un descripteur de l'objet créé.

Le descripteur a une taille de 8 octets. Syntaxiquement, les descripteurs d'objets dans MQL4 sont similaires aux pointeurs en C++.

Exemples :

MyObject* hobject= new MyObject();

Encore une fois, contrairement au C++, la variable hobject de l'exemple ci-dessus n'est pas un pointeur vers la mémoire, mais un descripteur d'objet.

Le camarade mql5 a clarifié la situation ici https://www.mql5.com/ru/forum/150943/page6#950107 . Je réagissais de façon excessive sans le savoir.
 

J'ai demandé au support technique pas plus tard qu'hier de séparer le fichier d'implémentation de la classe du fichier d'interface. Et j'ai eu une réponse :

В MQL нет файла проекта, фактически им выступает mq4 файл, а программа обязана иметь точки входа (при их отсутствии выдаётся ошибка "event handling function not found"). Поэтому при разделении интерфейса от реализации класса, файлом-реализации и интерфейса должны быть mqh файлы.

L'essentiel est que ce n'est pas une option logique. Après tout, le fichier contenant l'implémentation de la classe est un fichier d'implémentation, afin de le protéger des clients. Et si les deux sont sous une forme ouverte, c'est-à-dire au format .mqh, alors pourquoi avons-nous besoin de faire tout cela ?

 
hoz:

J'ai demandé au support technique pas plus tard qu'hier de séparer le fichier d'implémentation de la classe du fichier d'interface. Et j'ai eu une réponse :

L'essentiel est que cette option n'est pas logique. Après tout, le fichier contenant l'implémentation de la classe est un fichier d'implémentation, afin de le protéger des clients. Et si les deux sont sous forme ouverte, c'est-à-dire au format .mqh, alors pourquoi le faire ?

Je ne sépare jamais la déclaration de l'implémentation. J'écris tout dans un fichier d'en-tête. C'est beaucoup plus pratique. Vous devez suivre un seul fichier, pas deux. Je suis content s'il n'y a que trois méthodes dans une classe. Mais que se passe-t-il s'il y en a 100 ? Vous allez vous fatiguer à comparer les deux fichiers. Vous écrirez dans l'un et oublierez dans l'autre...

Il n'y a qu'un seul cas où il est nécessaire de diviser les fichiers. C'est lorsque deux ou plusieurs classes se réfèrent l'une à l'autre. De telles solutions sont à éviter. Ceci est vrai pour le C++. Je ne sais pas comment le faire dans MQL.

 

Dans le manuel, et en particulier, voici les codes :

//+------------------------------------------------------------------+
//| Класс, реализующий элемент списка                                |
//+------------------------------------------------------------------+
class CItem
  {
   int               m_id;
   string            m_comment;
   CItem*            m_next;
public:
                     CItem() { m_id=0; m_comment=NULL; m_next=NULL; }
                    ~CItem() { Print("Destructor of ",m_id,
                                     (CheckPointer(GetPointer(this))==POINTER_DYNAMIC)?
                                     "dynamic":"non-dynamic"); }
   void              Initialize(int id,string comm) { m_id=id; m_comment=comm; }
   void              PrintMe() { Print(__FUNCTION__,":",m_id,m_comment); }
   int               Identifier() { return(m_id); }
   CItem*            Next() {return(m_next); }
   void              Next(CItem *item) { m_next=item; }
  };
//+------------------------------------------------------------------+
//| Простейший класс списка                                          |
//+------------------------------------------------------------------+
class CMyList
  {
   CItem*            m_items;
public:
                     CMyList() { m_items=NULL; }
                    ~CMyList() { Destroy(); }
    bool             InsertToBegin(CItem* item);
    void             Destroy();
  };

Les champs suivants sont disponibles :

void              Next(CItem *item) { m_next=item; }

 bool             InsertToBegin(CItem* item);
Pourquoi le * est-il à droite dans un cas et à gauche dans l'autre ?
 
hoz:

Dans le manuel, et en particulier, voici les codes :

Il existe des champs comme celui-ci :

Pourquoi le signe * est-il à droite dans un cas et à gauche dans l'autre ?

C'est écrit. Ça n'a pas d'importance.

J'écris moi-même l'opérateur "*" pour désigner un pointeur à côté d'un type à sa droite (int*) et lors du déréférencement d'une variable à sa gauche (*pnVal).

 
Zhunko:

C'est ce qui est écrit. Ça n'a pas d'importance.

J'écris moi-même l'opérateur "*" pour désigner un pointeur à côté d'un type à sa droite (int*) et, lors du déréférencement, à côté d'une variable à sa gauche (*pnVal).

C'est ce que je pensais. Peut-être qu'un programmeur inattentif a écrit l'échantillon.

Il y a d'autres choses étranges :

 CItem*            m_next;

Cela signifie-t-il que la classe CItem se voit attribuer un descripteur d'objet m_next?

 
hoz:

Dans le manuel, et en particulier, voici les codes :

Les champs suivants sont disponibles :

Pourquoi le * est-il à droite dans un cas et à gauche dans l'autre ?

Ce n'est pas à gauche ou à droite, c'est entre les deux.
 
hoz:

C'est ce que je pensais. Je suppose qu'un programmeur inattentif a écrit l'exemple.

Il y a d'autres choses étranges :

Cela signifie-t-il que la classe CItem est associée au descripteur d'objet m_next?


Cela signifie qu'une instance doit être créée à l'aide de l'opérateur new.
1234567891011
Nouveau commentaire