Questions on OOP in MQL5 - page 4

New comment
 
Dmitry Fedoseev:
The pointer can also be passed by non-reference - without &.
Yes, you can. But if we pass a pointer without &, a new pointer is created on the stack to which the passed value is assigned. Moreover, if we allocate memory by this pointer in a function, it is the pointer created on the stack that changes, which means that we get memory leak when unrolling the stack. Of course, it's not good to do that, but if one wants to...
 
Vladimir Simakov:
If destructors are called in this way, the pointer created on the stack will be changed and, consequently, we get memory leaks when the stack is "unwound". Of course, it is not good to do that, but if one wants to...

the behavior of pointers to classes in MQL is not predictable, one of the admins once wrote that all classes are created in global memory (memory allocation), you write that pointers to classes in the local scope are created in the stack (imho, it should be so!)

Although I may confuse something, maybe I'll check it out - in theory it's not hard to check, it's enough to register Print() in destructor of test class, destructors must be called automatically when leaving local scope...

 
Vladimir Simakov:
Yes, they can. Only if we pass a pointer without &, a new pointer is created on the stack to which the passed value is assigned. And if we allocate memory by this pointer in a function, it is the pointer created on the stack that changes, so we get memory leak when unrolling the stack. Of course, it's not good to do that, but if one wants to...

There will be no leakage. Because no one is allocating anything to this pointer in the function.

 
Igor Makanu:

the behavior of pointers to classes in MQL is not predictable, one of the admins once wrote that all classes are created in global memory (memory allocation), you write that pointers to classes in the local scope are created in the stack (imho, it should be so!)

Although I may be confused by something, maybe I'll check it - in theory it's not hard to check, you just have to register Print() in destructor of test class, destructors must be called automatically when leaving local scope...

If memory is allocated dynamically (new), it is allocated in the heap and if you create an object on the stack (CObj obj;), memory is allocated to it on the stack too.

 
Dmitry Fedoseev:

There will be no leakage. Because nobody allocates anything to this pointer in the function.

void CreateLabel(CChartObjectLabel *l,string name,int y)
  {
   l=new CChartObjectLabel;
   l.Create(0,name,ChartWindowFind(),0,y);
   l.Color(clrYellow);
   l.FontSize(14);
   l.Description(name);
  }

This is a classic leak. The pointer created on the stack and initialized when being created with the value passed into the function was assigned a new value and became the pointer to a new object. After that, the pointer was safely killed when the stack is unfolded. Which is exactly what we needed to prove. This is exactly where it should be:

void CreateLabel(CChartObjectLabel* &l,string name,int y)
 
Vladimir Simakov:

If memory is allocated dynamically (new), it is allocated in the heap, and if you create an object on the stack (CObj obj;), memory is also allocated to it on the stack.

In mql there is no such thing - (CObj obj;).

 
Vladimir Simakov:

A classic leak. A pointer created on the stack and initialized on creation with the value passed into the function was assigned a new value and became a pointer to a new object. After that, the pointer was safely killed when the stack was unfolded. Which is exactly what we needed to prove. This is exactly where it should be:

Don't confuse God's gift with an egg. All the more reason to write idiotic code to prove an erroneous statement...

 
Dmitry Fedoseev:

No such thing in mql - (CObj obj;)

Come on! I use it all the time.
 
Vladimir Simakov: 
void CreateLabel(CChartObjectLabel *l,string name,int y)
  {
   l=new CChartObjectLabel;
   l.Create(0,name,ChartWindowFind(),0,y);
   l.Color(clrYellow);
   l.FontSize(14);
   l.Description(name);
  }

A classic leak. A pointer created on the stack and initialized on creation with the value passed into the function was assigned a new value and became a pointer to a new object. After that, the pointer was safely killed when the stack was unfolded. Which is exactly what we needed to prove. This is exactly where it should be:

Why would you intentionally reassign a pointer passed to a function? Of course, there will be a leak. But this is not a "classic leak", but a classic error of working with a pointer to an object.

You don't have to create a new object here, but handle the external object the pointer to which was passed into the function.

 
Vladimir Simakov:
Come on! I use it all the time.

Where? Where and how?

1234567891011...96
New comment