Questions on OOP (Object Oriented Programming) - page 8

 
C-4:
Typeid() unfortunately does not exist, and the strength of templates in the static identification. Different tasks are solved by different methods and to say that one method is bad and the other is good is an aggravating assumption.

I had a case where dynamic identification was needed. All solutions were very cumbersome, except for the universal type. Made through a class implementing a universal type.

But I got into trouble, too. Something has changed in STL (string) since VS 2012 and since then it won't compile. I haven't sorted it out yet.

 
Pavlick:

Huh, not pointers, but laughter on a stick.


The page at the second link in my post says:

In MQL4 you can dynamically create objects of complex type. This is done using the new operator, which returns the descriptor of the created object.

The descriptor has a size of 8 bytes. Syntactically, object descriptors in MQL4 are similar to pointers in C++.

Examples:

MyObject* hobject= new MyObject();

Again, unlike C++, the hobjectvariable from the above example is not a pointer to memory, but an object descriptor.


 
EverAlex:

The page at the second link in my post says:

In MQL4 you can dynamically create objects of complex type. This is done using the new operator, which returns a descriptor of the created object.

The descriptor has a size of 8 bytes. Syntactically, object descriptors in MQL4 are similar to pointers in C++.

Examples:

MyObject* hobject= new MyObject();

Again, unlike C++, the hobjectvariable from the above example is not a pointer to memory, but an object descriptor.

Comrade mql5 has clarified the situation here https://www.mql5.com/ru/forum/150943/page6#950107 . I was unknowingly overreacting.
 

I asked tech support not earlier than yesterday about separating the class implementation file from the interface file. And I got an answer:

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

The bottom line is that it's essentially not a logical option. After all, the file with the class implementation is an implementation file, in order to protect it from the clients. And if both of them are in an open form, i.e., in the .mqh format, then what for do we need to do this at all?

 
hoz:

I asked tech support not earlier than yesterday about separating the class implementation file from the interface file. And I got an answer:

The bottom line is that it's essentially not a logical option. After all, the file with the class implementation is an implementation file, in order to protect it from the clients. And if both of them are in open form, i.e. in .mqh format, then why do it at all?

I never separate the declaration from the implementation. I write everything in a header file. It's much more convenient. You have to keep track of one file, not two. I'm glad if there are only three methods in a class. But what if there are 100? You will get tired of comparing the two files. You'll write in one and forget in the other...

There is only one case when it's necessary to split the files. That's when two or more classes refer to each other. Such solutions should be avoided. This is true for C++. I don't know how to do it in MQL.

 

In the textbook, and in particular here are the 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();
  };

The following fields are available:

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

 bool             InsertToBegin(CItem* item);
Why is the * in one case on the right and in the other on the left?
 
hoz:

In the textbook, and in particular here are the codes:

There are fields like this:

Why is the * sign in one case to the right and in the other to the left?

It says so. It doesn't matter.

I myself write the "*" operator to denote a pointer next to a type to its right (int*) and when dereferencing a variable to its left (*pnVal).

 
Zhunko:

That's what it says. It doesn't matter.

I myself write the "*" operator to denote a pointer next to a type to its right (int*) and, when dereferencing, next to a variable to its left (*pnVal).

I thought so. Perhaps an inattentive programmer wrote the sample.

There are some other strange things there:

 CItem*            m_next;

Does it mean that the CItem class is assigned an object descriptor m_next?

 
hoz:

In the textbook, and in particular here are the codes:

The following fields are available:

Why is the * in one case on the right and in the other on the left?

It is not on the left or the right, it is between.
 
hoz:

That's what I thought. I guess an inattentive programmer wrote the example.

There are some other strange things there:

Does it mean that CItem class is assigned with object descriptor m_next?


This means that an instance has to be created using the new operator.
Reason: