Questions from a "dummy" - page 107

 
mql5:
Destructors in MQL5 are always virtual. Everything is deleted correctly, try to put Print(__FUNCSIG__); in destructors.


I did it in VC++, but I think memory release mechanisms are the same, right?
Документация по MQL5: Основы языка / Операторы / Оператор уничтожения объекта delete
Документация по MQL5: Основы языка / Операторы / Оператор уничтожения объекта delete
  • www.mql5.com
Основы языка / Операторы / Оператор уничтожения объекта delete - Документация по MQL5
 
220Volt:
I did it in VC++, but I think memory release mechanisms are the same?
No, in C++ you must specify virtual destructor to correctly delete object via delete.

But your example will work correctly, because you can specify virtual destructor only for base class.
 

I'll try to put the idea in a slightly different way:

Given:

  • Class #1 - it occupies 100 bytes in memory.
  • Class #2 - it is a descendant of class #1 and occupies 200 bytes in memory.
  • Pointer to class #1.

Actions:

  • Write into the pointer the address of the memory section where an instance of class #2 is located (call new)
  • Free solder area by passing the delete function to the address stored in the pointer.

P.S.: the figure shows memory model )

 
I have doubts because the pointer to class number one, but actually class number two is in memory. It does matter in case of destructors, so I wondered if there could be a problem here too. I think that in this situation correct memory freeing can occur only if there are some labels in memory (like char with null-terminator) or something like that, that's why I asked about memory allocation.
 
220Volt:
Doubts because the pointer to class number one, and actually in memory class number two. It does matter in case of destructors, so I was wondering if there may be a problem here too. I think that in such situation correct memory freeing can happen only if there are some labels in memory (like char with zero-terminator) or something like that, that's why I asked about memory allocation.

Your doubt is because you didn't specify constructors (it's important to understand what's going on in this case), try to run this example and you will understand everything:

class CFoo
  {
public:
                     CFoo() { Print(__FUNCSIG__); }
                    ~CFoo() { Print(__FUNCSIG__); }
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
class CBar : public CFoo
  {
public:
                     CBar() { Print(__FUNCSIG__); }
                    ~CBar() { Print(__FUNCSIG__); }
  };
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnStart()
  {
   CFoo *f=new CBar();

   delete f;
  }
//+------------------------------------------------------------------+

HZ the construction itself as well as the deletion is staggered, and all this information is stored (the virtual pointer itself remember that the class was constructed as a composite of the base and descendant), and when deleting, destructors are called in reverse order, from the later to the earlier one.

 
It's not about destructors, it's about the class itself, and more precisely how many bytes it occupies. It turns out that we allocate 200 bytes, and then tell me to free up the memory, which is pointed by a pointer representing an object of size 100 bytes.
 
220Volt:
It's not about destructors, it's about the class itself, and more precisely how many bytes it occupies. It turns out that we allocate 200 bytes and then tell me to free the memory pointed to by the pointer representing the object with the size of 100 bytes.
I take it that your question is related to the way the memory pool works.
Yes, the memory pool knows how long a piece of memory will be freed by a delete call.
Where this information is stored depends upon the pool's implementation.

For example, if you give a pointer to an object in C++ which is not allocated through new, you'll see how your application will crash.
 
220Volt:
It's not about destructors, it's about the class itself, and more precisely how many bytes it occupies. It turns out that we allocate 200 bytes and then tell me to free the memory pointed to by the pointer representing the object with the size of 100 bytes.
I take it you haven't run my sample. Otherwise you wouldn't have asked such questions.
 
I was thinking, I remembered that you can allocate memory for an array of int's for example and then delete all of them, despite the fact that one int is small, probably the same with classes. Thanks for the answers.
 
mql5:
I understand your question has to do with the way the memory pool works.
Yes, the memory pool knows how long a piece will be freed by a delete call.
Where this information is stored depends on the pool's implementation.

For example, if you give a pointer to an object in C++ that wasn't allocated through new, you'll see how your application will crash.
That's about it, thank you.
Reason: