Questions on OOP in MQL5 - page 9

New comment
 
Igor Makanu:

what tonnes are we talking about? everything that was overlooked will be reported by the terminal, the place where to delete it is also known - OnDeint() .... Has this discussion turned into a discussion of a spherical horse in a vacuum? )))

No. Let the horse ride where it should.

But we are discussing creation of previously unknown objects. And we don't know not only their properties, but the number of created objects themselves as well.

Of course, for one object we can create a pointer and work with that object by this pointer. But if we don't know beforehand how many pointers we'll need, what kind of vacuum is this? It is only one of the simplest and immediately available - to store pointers in lists. They can be taken from the list. Well, each object can have its own identifier (the Type() method), by which you can identify the pointer object. It's possible to precisely identify an object (in addition to its type object can be endowed with other properties, which distinguish it from the objects of the same type).

In general - it feels like I'm talking about more complex structures, which require classification of objects, lists for their storage and methods of working with objects that can not only store and give information upon request, but also "live and grow" interacting with the program, from time to time themselves changing and reporting about their actions.

Perhaps I went too far and we just need to discuss an object where two fields must be changed during initialization and they must not change in any way during the lifetime of the object. What's the point of having an object if there are input variables?

 
No one is obliged to remove an object except the one who created it. Even if it does happen in some cases, it is not to be trusted. If you created it, you delete it.
 
Dmitry Fedoseev:
No one is obligated to delete an object, except the one who created it. Even if this happens in some cases, it is not to be trusted. If you created it, you delete it.

That's true. But that's not what we're talking about. Isn't it?

We're talking about methods by which objects are definitely not lost, and you can unambiguously find them.

When you create an object, be aware of it and don't lose it, so that it's properly deleted later and there's no memory leak due to a lost object pointer (we started with the memory leak in the example where the pointer to the object passed into the function was reassigned to the newly created object in the function body).

And everyone has their own preferences - some like one thing, some like another. But we have to know about each of our objects - even if there are two or two thousand and two of them - so that we can delete them later. And whether we will delete them ourselves by delete or let list delete them by Clear() or in loop by list and delete or some other way - it's not about that.

 
Artyom Trishkin:

In general, I feel that I am talking about more complex structures, which require classification of objects, lists for their storage and methods of working with objects, which can not only store and give information on request, but also "live and evolve" interacting with the program, from time to time changing themselves and reporting about their actions.

Perhaps I went too far and we just need to discuss an object where two fields must be changed at initialization and they must not change in any way during the lifetime? What's the point of having an object if there are input variables?

This is a strange concept of OOP. First of all, OOP is convenient - you write it once and then create new instances of the object.

Going back to the beginning of the discussion, here's my example, I often use ithttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

I need to limit my trading to one time interval now and 2 next time... 4...

my 2 click example is modified for this task:

int OnInit()
{
   Work1=new CWorkTime(StartHour1,StartMinute1,StopHour1,StopMinute1);
   Work2=new CWorkTime(StartHour2,StartMinute2,StopHour2,StopMinute2);
   Work3=new CWorkTime(StartHour3,StartMinute3,StopHour3,StopMinute3);
   Work4=new CWorkTime(StartHour4,StartMinute4,StopHour4,StopMinute4);
}


I don't know, but thinking in categories that OOP is just for wrapping everything in a class and there it is a miracle - my superclass and it can do both... And if the class is 10 strings, you don't need OOP - why limit yourself and mislead everyone?

I use OOP where it's convenient for me, the discussion has clearly gone to religion - to forbid or use OOP ))))

 
Igor Makanu:

This is a strange idea of OOP, OOP is first of all convenient - write once, then create new instances of the object

Going back to the beginning of the discussion, here's my example, I often use ithttps://www.mql5.com/ru/forum/160683/page861#comment_11840254

I need to limit my trading to one time interval now and 2 next time... 4...

my 2 click example is modified for this task:


I don't know, but thinking in categories that OOP is just for wrapping everything in a class and there it is a miracle - my superclass and it can do both... And if the class is 10 strings, you don't need OOP - why limit yourself and mislead everyone?

where it's convenient for me, that's where I use OOP, clearly the discussion has gone to religion - to forbid or use OOP ))))

Definitely - I'm not the one who is going into this religion, since I actively use OOP myself.

For example: what if we need some more intervals? Should we create new ones? What for? If you can do with one list without interfering with the program code.

We seem to be talking about different things. I'm talking about usability, and you're... I'm talking about usability, too, but you're showing code that's not convenient. Maybe just exaggerated of course, and I didn't understand it...

 
Artyom Trishkin:

For example: What if more intervals are needed? Should new WorkNNNs be created? What's the point? If you can manage with one list without interfering with the program code...

If we need to use lists or arrays of class instances, it's not a big deal, but it's easier to use an array for this example, and we'll just do one loop:

bool DisableTrade=false;
   for(int i=0;i<ArraySize(Work);i++)
     {
      if(Work[i].Disable()) {DisableTrade=true; break}
     }
   if(DisableTrade)
     {
      Comment("Не торговое время!!! Сопровождение открытых ордеров");
     }
   else...

Artyom Trishkin:

We seem to be talking about different things. I'm talking about usability, and you ... I'm talking about usability too, but the code you're showing isn't convenient. Maybe it's just exaggerated, of course, and I didn't understand it...

Unfortunately it is impossible to write universal code. Even if you do write universal code, its further modification will be a tedious process and as a consequence universal code will be more resource-intensive - in general you may speak about this forever, once I wrote, as one of the famous programmers said -"the code must perform its task! - that's enough". All the rest is ... well it's a desire to mess around or... let's say to create! )))

 
Artyom Trishkin:

///

For example: what if more intervals are needed? Should new WorkNNNs be created? What's the point? If you can manage with one list without interfering with the program code.

///

Then there will be no numeric interval parameters in the properties window. You will not be able to optimize them. Not an option.

Creating a new object for each interval is also not the best option. Still it will lead to slower performance. If we were to create a class, we should create one that would add the parameters of intervals into an array. It will be faster.

 
Dmitry Fedoseev: rmosa. If you have to make a class, it should be such, that it would add parameters of intervals into an array. It will be faster.

it makes absolutely no difference if you make one class or a function into which you add() several parameters, if you create several classes with individual parameters

SZZ: do not forget that if you write one big function in the form of a long "horse-tape" - the CPU cache will not always be effectively used, although there may be a gain in such a "horse-tape" when predicting transitions.... only testing can show that, but on a specific PC and on a specific compiler...

 
Dmitry Fedoseev:

Then there will be no numerical interval parameters in the properties window. You will not be able to optimise out of it. Not an option.

Creating a new object for each interval is not the best option either. After all, this will lead to slower performance. If we were to create a class, we should create one that would add the parameters of intervals into an array. It would be faster.

Agreed. Again, it all comes down to the methods for setting the checkout fields. And how to transfer them from input parameters to the object storing all intervals is a matter of technique. Although it is possible to recreate all objects in the list of intervals and when you change only one of them - it's a matter of practicality and "bothering/not bothering" to change the data when writing the code.

 
Roman:

Can you explain the sense of creating a dynamic object using the new operator?

When an object is created automatically, the class object is created in the stack and it is faster than a dynamic object in terms of execution time.
When creating an object dynamically, a class object is created in memory (in the heap) involving OS memory manager, the process is slower.

Here are the questions:
If automatic creation is faster, then why is it better to use dynamic objects?
Explicitly control memory allocation?
Eliminate a possible stack overflow?
And not to lose an object unexpectedly?
Because if the stack overflows, the object will be automatically deleted?

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 access to the delete operator directly, 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:)

12345678910111213141516...96
New comment
Reason: