![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
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?
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:
Actions:
P.S.: the figure shows memory model )![](https://c.mql5.com/3/7/xnajoemxmx.png)
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:
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 the memory pointed to by the pointer representing the object with the size of 100 bytes.
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.
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 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.