Help with OOP - page 2

New comment
 
Ihor Herasko #:
If you suddenly want to argue with Renate, welcome.

er, like this:

Ihor Herasko #:

One more thing. Object arrays are best created via a pointer. Otherwise you get an array in stack memory, which is very small:

has nothing to do with what Renat says and the above examples.
 
Ihor Herasko #:

If you modify the example a bit by making the declaration at the local level and putting a not so terrible number, the compiler tells you directly what the problem is:

If you ever want to argue with Renate, you 're welcome to do so.

In your example:

Test *pClassTest[];

Is defined outside the function, as a global variable. So what's the stack here? It is a heap.

 
Vasiliy Sokolov #:

In your example:

is defined outside the function as a global variable. So what's the stack here? It's a heap.

Amazing! Vasily, you got into an argument without understanding what you're arguing about, and without making any effort to understand what the argument is about?

Igor is both arguing in the heap, and this line of code is from the second ("correct") example, which compiles, unlike the first, which does not compile (and has no pointer in it).

 
Ihor Herasko #:

If you modify the example a bit by making the declaration at the local level and putting a not so terrible number, the compiler tells you directly what the problem is:

If you suddenly want to argue with Renate, you're welcome.

On the subject of "not terrible". How to say. The stack is 1 MB by default and you allocate ARRAY_SIZE*sizeof(Test) on it, which is obviously larger.

 
Ihor Herasko #:

It's not a problem, much less a potential problem. It's just the peculiarities of memory handling in MT. Here is a static array:

And here is a dynamic array:

In this case, everything compiles and works.

Let's move on.

In the first case, memory is allocated at compile time. That is, the .data segment of the program should include these ARRAY_SIZE*sizeof(Test). What was ARRAY_SIZE there?)) If I'm not mistaken, under 2TB the .ex5 file comes out))))

In the second case, just goes the allocation in the ARRAY_SIZE*sizeof(Test*) bytes pile, i.e. 480GB,

 

double x[268435448]; in the general section compiles.

268435449 does not compile anymore.

And268435449 compiles in OnStart() of the script; I left this huge array x in the general section.

268435448*8=2,147,483,584 is two gigs.

***

And here is the limit in the function: double x[268435456];

 

See reference about stack:

Indicates stack size for MQL5 program, sufficient stack size is required in case of recursive function calls.

When launching a script or an Expert Advisor on a chart, at least 8 Mb stack is allocated, for indicators the property does not work - the stack is always fixed at 1 Mb.

When launched in the tester, the program always allocates stack of 16 Mb.


We should suppose that the stack is used only for recursive function calls. Therefore, no matter what size static arrays are, for recursive calls the stack will remain as it is.

 
Dmitry Fedoseev #:

Amazing! Vasiliy, did you get into an argument without understanding what you are arguing about, and without making any effort to understand what the argument is about?

Igor both argues in the heap, and this line of code is from the second ("correct") example, which compiles, as opposed to the first, which does not compile (and has no pointer in it).

Ok. I don't get it. Do you understand? Do you understand exactly? Exactly exactly?

The argument boils down to the following statement:

Forum on trading, automated trading systems and trading strategy testing

Help with OOP

Ihor Herasko, 2021.09.19 21:00

And one more thing. It's better to create arrays of objects by using a pointer. Otherwise you'll get an array in the stack memory which is very little:

Strategy2 *pZ[];

This is an incorrect statement. Arrays are not allocated in the stack. Neither through pointers nor statically. This is easy to check.

The second point: the example uses pointers but they are not needed there. Here is the equivalent example without the bareplate:

#define               ARRAY_SIZE           int(60000000)
class Test
{
public:
   int               nA;
   double            fB;
   datetime          dtC;

                     Test(void)
                       : nA(0)
                       , fB(1.0)
                       , dtC(__DATETIME__)
                     {
                     };
};

Test pClassTest[];
 
void OnStart()
{
   if (ArrayResize(pClassTest, ARRAY_SIZE) != ARRAY_SIZE)
   {
      Alert("Not enought memory");
      return;
   }
}

The same 60,000,000 objects are allocated with a default constructor call. And there's no need to initialize manually and then free memory which saves significant (many times) time while making the code much safer, simpler and local.

Checking. Let's break and open it in process manager. Here in ProcessHacker:

In the private area, 4 and 2 GB are allocated respectively.

Checking stack size:


The script stack is 8 MB and this is the maximum stack.

It is easy to apply logic in your head and calculate that 60 000 000 objects sized 20 bytes each will occupy over 1 Gbyte of memory. No stack will be enough to fit it all in.

Besides, both samples (with and without pointers) give the same profiling. Nothing is allocated in the stack. However, the example with pointers allocates 1 GB more memory, it's easy to see that too.

Note that you can't just change the maximum size of the stack at runtime. The maximum size of the stack is predefined and set beforehand, e.g. during compilation.

s.s. Purely theoretically, it's possible to allocate small static arrays on stack (in mql it won't be explicit). But it can lead to big problems, because user may easily create several such arrays, even in different linked functions, and overflow the stack. That's why users should be protected from such self-shooting and always allocate arrays in shared memory regardless of their size.

 
Dmitry Fedoseev #:

double x[268435448]; in the general section compiles.

268435449 does not compile anymore.

And268435449 compiles in OnStart() of the script; I left this huge array x in the general section.

268435448*8=2,147,483,584 is two gigs.

***

And here is the limit in the function: double x[268435456];

These are the code analyzer's limitations. It is not really a problem to allocate 4 or 6 or 20 Gb of memory in mql if you have it.

 
Vasiliy Sokolov #:

always allocate arrays in shared memory regardless of their size.

Not to use static arrays?

123456789
New comment
Reason: