Questions on OOP in MQL5 - page 11

 
Dmitry Fedoseev:

And speaking of birds... descriptors are also pointers. And you know, nothing changes from the word itself, whether it's a descriptor, a pointer, an identifier.

the physical implementation of these words has long been hidden from users

imho it's more or less like this

- descriptor - is tied to the method that implements this functionality in the system

- a handle - everything is the same as a descriptor, but the OS implements it

- a pointer and identifier are meant to work with physical memory

 
Dmitry Fedoseev:

And if you have to pass a pointer to a function to create an object in the function, that's how it works:

class CObj{
   public:
   int f(){
      return(33);
   }
};

CObj * obj;

void OnStart(){
  z(obj);
  delete(obj);
}

void z(CObj & o){
   o = new CObj();
}
That's actually all you wanted to know about OOP, but were afraid to ask)))

Uh-huh, genius.

These 17 lines are actually all you need to know about Fedoseev's qualification as a programmer.

2019.07.05 15:19:56.309 invalid pointer access in 'test13.mq5' (11,5)

 
Vasiliy Sokolov:

Good afternoon. Computer memory has the same performance regardless of whether it is used in a stack or heap context. Dynamic memory management itself depends on rubbish collector implementation: for example, it can be reference counting as in Python (slower variant) or analysis of object generation epochs with execution graph traversal in background process (Net CLR). Which variant is used in MQL is unknown, but we can assume that it is extremely efficient, because the user of MQL5 has the delete operator directly available, which greatly simplifies the work of GC itself. Therefore, your concerns about overhead when using new are groundless - feel free to use dynamic memory.

As for "stack overflow", the only way you may encounter this case in modern systems is when using complex recursion or making a mistake in the recursive algorithm. A modern program always works in OC protected mode in virtual address space, with dynamic loading of memory pages, so don't worry: the stack will not overflow:)

Thank you for clever explanation.
For some reason I thought that in mql calling on the stack is faster than on the heap, especially since we don't know the implementation of the rubbish collector.
That's why I've got such questions, what's better to use to speed up object creation, auto or dynamic.
Yes, I understand that everything depends on the specific task, but for example, let's take sending of trade requests.
And our task is to create the most correct objects for quick processing performance.
We have a custom class with described methods of trade requests.
We know the number of class instances and its methods.
And as you suggest, "the stack will not end".

Hence my question is: which method is better to create and delete objects? Automatically or dynamically?
I had an idea to do synthetic management of automatic objects in general.
That is, declare automatic objects in the body of the user's function.
This way, the object is created on the stack (in theory, it is faster than the heap). We don't have to worry about automatic object deletion because the object variable is declared in the user-defined function
and the automatic object will be additionally checked for destroying by the user function itself, according to the rule of dynamic variables in functions.
That's why I would like to listen to the adequate opinions of the participants of this branch, who thinks in this regard.

 
TheXpert:

Mm-hmm, genius.

Those 17 lines are actually all you need to know about Fedoseev's qualifications as a programmer.

2019.07.05 15:19:56.309 invalid pointer access in 'test13.mq5' (11,5)

Amazing. And I both compile without errors (right now) and it works correctly.

Next time, draw in photoshop.

 
Roman:

Thank you for clever explanation.
For some reason, I thought that calling on the mql stack is faster than on the heap, especially since we don't know how the rubbish collector is implemented.
That's why I've got such questions, what's better to use to speed up object creation, auto or dynamic.
Yes, I understand that it all depends on the specific task, but for example, let's take sending of trade requests.
And our task is to create the most correct objects for quick processing performance.
We have a custom class with described methods of trade requests.
We know the number of class instances and its methods.
And as you suggest, "the stack will not end".

Hence my question is: which method is better to create and delete objects? Automatically or dynamically?
I had an idea to do synthetic management of automatic objects in general.
That is, declare automatic objects in the body of the user's function.
This way, the object is created on the stack (in theory, it is faster than the heap). We don't have to worry about automatic object deletion because the object variable is declared in the user-defined function
and the automatic object will be additionally checked for destroying by the user function itself, according to the rule of dynamic variables in functions.
That's why I would like to listen to the adequate opinions of the participants of this branch, who thinks in this regard.

You thought right. Accessing objects created with new is much slower. And there is no rubbish collector here.

 
Igor Makanu:

the physical implementation of these words has long been hidden from users

imho like this:

- descriptor - tied to a method that implements this functionality in the system

- a handle - everything is the same as a descriptor, but the OS implements it

- a pointer and an identifier imply that this is an operation in physical memory.

And it doesn't make any difference to us how it works.

 

A word of advice on another issue. If you create a child class CMyButton from CButton, you can create a button and then change its properties outside the class. Below this is done in OnInit().

But if I want to make additional fields inside the child class and use the built-in properties of the CButton class in new functions, how can I do this correctly?

In the CButton class, the m_button class member is declared in the private section.

#include <Controls\Button.mqh>

class CMyButton : public CButton
{ 
  private: 

  public: 
              CMyButton(void){}; 
             ~CMyButton(void){}; 
             
        bool    isPrevState;        // состояние кнопки на предыд.тике, true - была нажата     
        void    setButton();        // создаем кнопку
        void    setProp();          // задаем в ходе программы свойства
}; 

void CMyButton::setButton(void)
{
  // как в этой функции создать кнопку? Я не могу вызвать метод Create()
}

//+------------------------------------------------------------------------------------------------------------------+
//| 
//+------------------------------------------------------------------------------------------------------------------+

CButton Btn;
CMyButton MyBtn;

int OnInit()
  {
  
   Btn.Create(0, "Btn", 0, 50, 50, 120, 75);
   Btn.Text("Standart");
   MyBtn.Create(0, "MyBtn", 0, 50, 200, 150, 225);
   MyBtn.Text("MyBtn");
   
   return(INIT_SUCCEEDED);
  }
 
Dmitry Fedoseev:

Yeah, it deletes and writes a message about memory leaks, just so that the programmers who write EAs don't get bored with their lives.

It's interesting how yesterday there was a memory leak and today there can't even be one.

And speaking of birds... descriptors are also pointers. And you know, the word itself doesn't change anything, whether it's a descriptor, a pointer, an identifier.

The leakage comes from the address space of the process. When you leak in while(true) loop, your program will eventually crash at the next memory allocation from the heap, which has run out.
 
Dmitry Fedoseev:

And I both compile without errors (right now) and it works correctly.

Yep, already two unrelated people are photoshopping your code's crash )

Your code can't work correctly, it's obvious by the code itself ))

 
TheXpert:

Yep, two unrelated people are already photoshopping your code )

Your code can't work properly, it's obvious from the code itself ))

Just now, wanted to write the same thing))))