Help with OOP - page 3

New comment
 
Vasiliy Sokolov #:

OK. I don't understand. Do you understand? Are you sure you understand? Exactly?

The argument boils down to the following statement:

...

That was not about a general argument, but about a situation concerning a single post, and I explained what the problem was. Okay, there was no catastrophe.

 

Declared array double x[268435448];

The same array in OnStart() function.

Also made a recursive call with LONG_MAX depth.

No problems.

 
fxsaber #:

Don't use static arrays?

large. if the size of the array is small, constant and known in advance, static is better and probably faster.

 
Andrei Trukhanovich #:

large. if the size of the array is small, constant and known in advance, static is better and probably faster.

I would like to have a way to get a list of static variables/arrays and their sizes. Probably need a code parser like done here.

I guess static string array and double array are quite different things.

MQL5 Program Packer
MQL5 Program Packer
  • www.mql5.com
This is MQL5 project packer: assemble all source and resource files from dependencies into a single ZIP.
 
fxsaber #:

I guess static string-array and double-array are quite different things.

string is essentially an internal class consisting of a pointer and int size, i.e. for double array will occupy conditionally 1.5 times less space

I don't think that there's much sense to bother with it, unless you have static arrays with millions of elements.

 
fxsaber #:

Not to use static arrays?

So there are essentially four types of data in MQL:

  • Static, predefined data. Stitched into the program at compile time and is no longer modified. They are located in a private memory space. For example, these are static arrays of char[1024] type.
  • Manually managed data through the pointers. These are instances of classes but defined by pointer, for example CFoo* bar where bar is an instance of CFoo. These instances are of type POINTER_DYNAMIC. This storage type is the most problematic, although it's not required in most cases.
  • Data managed by the rubbish collector of the mql virtual machine in which the program is running. This includes instances of classes. Pointer to an object of this type will be POINTER_AUTOMATIC. Such objects themselves are either in heap of this virtual machine or in private section. Exactly how depends on the data and its size, apparently, and whatever the developers have. This information is not available. Such data include user classes, for example. Any definition of a class instance without a pointer defines this storage type. For example CFoo bar defines an instance of bar class CFoo, the pointer to which does not need to be freed. The virtual machine performs all the operations of releasing. You don't need to use the delete operator and therefore face the problem of leaked objects.
  • Data located on the stack. These are, first of all, local variables of functions. I.e. when we write int a = 5 inside any function, the top of the stack is moved 4 bytes up, thus allocating the needed memory size. Perhaps, in MQL, types stored on the stack include structures as well (I've never checked, to be honest). Such data take not much place, and even taking into account a chain of calls of nested functions, the stack as a whole requires much less memory than a heap. This type of storage is used automatically, you don't have to think about it.

If we leave the stack to functions and their local variables, we are left with three types to work with. I personally believe (and this is just my opinion) that data defined with automatic lifetime combines well the advantages of the previous two types, without their disadvantages. Data defined with automatic pointer is as well predictable and safe as static, yet just as flexible as dynamic, manually controlled data. By predictability I mean in scenarios where there's no need to do additional pointer bit checks and wonder if someone else has already deleted the data before. By flexibility I mean scenarios where one can work with data referenced by an auto-pointer like with a regular pointer, by passing the pointer to a function, or, for arrays, by recycling it.

To illustrate what I've just said, you can compare the initial code provided by Ihor Herasko and the same code I've written for POINTER_AUTOMATIC. There are no extra checks and initializations, no operator delete 60 000 000 times. All this saves you time, effort and, what's also important, resources. If you understand it, you almost never need to work with pointers. You can always write such an algorithm that would either minimize this work or stay at all. For example, I never handle objects manually in my code - there's just no need in that somehow. As for static arrays, then sometimes I have to use, for example, to sew into the program the data it needs, but it's so special things, that ordinary users, I assume, don't need them. It is best to use ready-made collections such as CArrayObj, or your own. Now templates and MQL capabilities allow you to create quite flexible things that are much better than static arrays.

 
There is no trash collector in the emcool.
 

Vasiliy Sokolov #:

Static, predefined data. Stitched into the program at compile time and no longer modified. They are stored in some private memory area. For instance, these are static arrays like char[1024].

If the array is not initialized,

int A[] = {1, 2}; // Инициализация
int B[2];         // Без инициализации

why should it be written into EX5?

 
fxsaber #:

If the array is not initialised,

why should it be stitched into EX5?

Yes, that's right, uninitialized ones are not sewn in, of course. The initialized ones do. But the sizes of both types are defined at compilation time and don't change anymore. That is, static arrays may be conditionally divided into two groups.

 
Dmitry Fedoseev #:
There is no rubbish collector in emcool.

Officially, yes. Unofficially, many things indicate that it does exist:

  • There are no pointers in MQL. Instead, they are replaced by something that looks a lot like them.
  • There is no direct memory allocation in MQL, as in C for example;
  • Programs in MQL are executed by a certain virtual machine. Renat wrote about it briefly and not once;
  • The class instance can be defined that will be released automatically. So, there is some mechanism that monitors these instances and releases them when necessary. What is that if not a rubbish collector?
  • Any instances initialized through a pointer and not properly freed will be marked as leaked objects on exit. Their number and total size of lost memory will be printed. A program with leaked memory will not even be validated in Market. Hence all objects, even manually allocated ones, are accounted for, known and known to the system. This is one of the classic tasks that the rubbish collector solves.
123456789
New comment