Fragen zu OOP (Objektorientierte Programmierung) - Seite 8

 
C-4:
Typeid() existiert leider nicht, und die Stärke von Vorlagen in der statischen Identifikation. Unterschiedliche Aufgaben werden mit unterschiedlichen Methoden gelöst, und zu sagen, dass die eine Methode schlecht und die andere gut ist, ist eine erschwerende Annahme.

Ich hatte einen Fall, in dem eine dynamische Identifizierung erforderlich war. Alle Lösungen waren sehr umständlich, mit Ausnahme des Universaltyps. Hergestellt durch eine Klasse, die einen universellen Typ implementiert.

Aber ich bin auch in Schwierigkeiten geraten. Etwas hat sich in STL (String) seit VS 2012 geändert und seitdem lässt es sich nicht kompilieren. Ich habe das noch nicht geklärt.

 
Pavlick:

Hm, keine Zeiger, sondern Lachen am Stiel.


Auf der Seite unter dem zweiten Link in meinem Beitrag steht:

In MQL4 können Sie Objekte komplexen Typs dynamisch erstellen. Dies geschieht mit dem Operator new, der den Deskriptor des erstellten Objekts zurückgibt.

Der Deskriptor hat eine Größe von 8 Byte. Syntaktisch sind Objektdeskriptoren in MQL4 ähnlich wie Zeiger in C++.

Beispiele:

MyObject* hobject= new MyObject();

Auch hier ist die hobject-Variable aus dem obigen Beispiel imGegensatz zu C++ kein Zeiger auf den Speicher, sondern ein Objektdeskriptor.


 
EverAlex:

Auf der Seite unter dem zweiten Link in meinem Beitrag steht:

In MQL4 können Sie Objekte komplexen Typs dynamisch erstellen. Dies geschieht mit Hilfe des new-Operators, der einen Deskriptor des erstellten Objekts zurückgibt.

Der Deskriptor hat eine Größe von 8 Byte. Syntaktisch sind Objektdeskriptoren in MQL4 ähnlich wie Zeiger in C++.

Beispiele:

MyObject* hobject= new MyObject();

Auch hier ist die hobject-Variable aus dem obigen Beispiel imGegensatz zu C++ kein Zeiger auf den Speicher, sondern ein Objektdeskriptor.

Genosse mql5 hat die Situation hier https://www.mql5.com/ru/forum/150943/page6#950107 geklärt . Ich habe unbewusst überreagiert.
 

Erst gestern habe ich den technischen Support gebeten, die Implementierungsdatei der Klasse von der Schnittstellendatei zu trennen. Und ich bekam eine Antwort:

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

Unterm Strich ist es im Grunde keine logische Option. Schließlich ist die Datei mit der Klassenimplementierung eine Implementierungsdatei, um sie vor den Clients zu schützen. Und wenn beide in offener Form vorliegen, d.h. im .mqh-Format, wozu brauchen wir das dann überhaupt?

 
hoz:

Erst gestern habe ich den technischen Support gebeten, die Implementierungsdatei der Klasse von der Schnittstellendatei zu trennen. Und ich bekam eine Antwort:

Unterm Strich ist es im Grunde keine logische Option. Schließlich ist die Datei mit der Klassenimplementierung eine Implementierungsdatei, um sie vor den Clients zu schützen. Und wenn beide in offener Form vorliegen, d.h. im .mqh-Format, warum dann überhaupt?

Ich trenne nie die Deklaration von der Implementierung. Ich schreibe alles in eine Header-Datei. Das ist viel bequemer. Sie müssen eine Datei im Auge behalten, nicht zwei. Ich bin froh, wenn es nur drei Methoden in einer Klasse gibt. Was aber, wenn es 100 sind? Sie werden es leid sein, die beiden Dateien zu vergleichen. Du schreibst in der einen und vergisst in der anderen...

Es gibt nur einen Fall, in dem es notwendig ist, die Dateien aufzuteilen. Das ist der Fall, wenn sich zwei oder mehr Klassen aufeinander beziehen. Solche Lösungen sollten vermieden werden. Dies gilt auch für C++. Ich weiß nicht, wie man das in MQL macht.

 

Im Lehrbuch und insbesondere hier sind die 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();
  };

Die folgenden Felder sind verfügbar:

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

 bool             InsertToBegin(CItem* item);
Warum ist der * in einem Fall rechts und im anderen Fall links?
 
hoz:

Im Lehrbuch und insbesondere hier sind die Codes:

Es gibt Felder wie dieses:

Warum steht das *-Zeichen in einem Fall rechts und im anderen links?

So steht es dort. Das spielt keine Rolle.

Ich selbst schreibe den "*"-Operator, um einen Zeiger neben einem Typ zu seiner Rechten (int*) und beim Dereferenzieren einer Variablen zu seiner Linken (*pnVal) zu bezeichnen.

 
Zhunko:

So steht es hier. Das spielt keine Rolle.

Ich selbst schreibe den Operator "*", um einen Zeiger neben einem Typ auf der rechten Seite (int*) und beim Dereferenzieren neben einer Variablen auf der linken Seite (*pnVal) zu bezeichnen.

Das dachte ich mir schon. Vielleicht hat ein unaufmerksamer Programmierer das Beispiel geschrieben.

Dort gibt es noch einige andere seltsame Dinge:

 CItem*            m_next;

Bedeutet dies, dass der Klasse CItem ein Objektdeskriptor m_next zugewiesen wird?

 
hoz:

Im Lehrbuch und insbesondere hier sind die Codes:

Die folgenden Felder sind verfügbar:

Warum ist der * in einem Fall rechts und im anderen Fall links?

Es ist nicht links oder rechts, es ist dazwischen.
 
hoz:

Das habe ich auch gedacht. Ich vermute, ein unaufmerksamer Programmierer hat das Beispiel geschrieben.

Dort gibt es noch einige andere seltsame Dinge:

Bedeutet dies, dass der Klasse CItem der Objektdeskriptor m_next zugewiesen ist?


Dies bedeutet, dass eine Instanz mit Hilfe des new-Operators erstellt werden muss.