Help with OOP

[Dmitiry Ananiev]

I'm making a class like this.

class Strategy1
{
        Strategy1();
 };

class Strategy2
{
        Strategy (string sym);
}

Now I want to call an object array:

Strategy1 S[10];  // компилируется 
Strategy2 Z("EURUSD")[10]; // не компилируется 

How then to quickly create an array of objects if the constructor has parameters at global level?

For example? create objects first by changing the constructor and then how do I replace the objects in OnInit with symbols?

Maybe there is an easier solution ?

[Georgiy Merts]

Personally, I use the Init() function on objects in such cases.

First, an array is created, and then Init() function is called for all objects in the array, where all parameters can be set.

Initialization with separate function allows to re-initialize objects, and if you initialize in constructor, you can't re-initialize the object.

[Dmitiry Ananiev]

Georgiy Merts #:

Personally, I use the Init() function on objects in such cases.

First, an array is created, and then Init() function is called for all objects in the array, where all parameters can be set.

The initialization with a separate function allows to re-initialize objects, and if you initialize it in the constructor, it's impossible to re-initialize the object.

Well, that's how I imagined it. Thanks !

[Ihor Herasko]

One more point. It's better to create arrays of objects by means of a pointer. Otherwise you will get an array in stack memory, which is very small:

Strategy2 *pZ[]; 
if (ArrayResize(pZ, 10) != 10)
{
   Alert("Memory allocation error");
   return;
}

for (int i = 0; i < 10; ++i)
{
   pZ[i] = new Strategy2("EURUSD"); 
   if (CheckPointer(pZ) == POINTER_INVALID)
   {
      Alert("Class instantiation error");
      return;
   }
}

[fxsaber]

Ihor Herasko #:

One more point. It's better to create arrays of objects by means of a pointer. Otherwise you will get an array in stack memory which is very low:

An example of a potential problem would be nice.

[Vasiliy Sokolov]

Ihor Herasko #:

One more point. It's better to create arrays of objects by means of a pointer. Otherwise you will get an array in stack memory which is very small:

Ouch.

[TheXpert]

It's no big deal.

[Ihor Herasko]

fxsaber #:

An example of a potential problem would be good.

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

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

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

Test classTest[ARRAY_SIZE];                   // 'classTest' - global variables section is too large
 
void OnStart()
{
}

And here is a dynamic array:

#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;
   }
   
   for (int i = 0; i < ARRAY_SIZE; ++i)
   {
      pClassTest[i] = new Test();
      if (CheckPointer(pClassTest[i]) == POINTER_INVALID)
      {
         Alert("Class instantiation error");
         return;
      }
   }

   for (int i = 0; i < ARRAY_SIZE; ++i)
      delete pClassTest[i];
}

In this case, everything compiles and works.

[Vasiliy Sokolov]

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.

What's the stack got to do with it? In the first case, you have tried to statically (at the compilation stage) allocate a large block of memory in a heap and the compiler justly kicked you in the forehead because it is not quite clear in reality whether you can allocate that much memory or not.

In the second case you are allocating a large chunk of memory already in runtime. And it is immediately clear whether you can allocate it or not, because the program is already working with a specific resource of the machine (memory).

And what do pointers have to do with it? Arrays in mql are of two types, predefined at compile time and dynamic. Not only pointers *, but usual class fields can point to dynamic arrays as well. So using pointers here is absolutely not justified.

s.e. Strange impression of the code, like pointers, classes, macros - with complete lack of understanding of what's going on.

[Dmitry Fedoseev]

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.

Wrong example, it's just a limitation of the compiler that doesn't say anything, the developers just decided so.

If there were two versions - one of them has a large static array and the other one has a small one and, lo and behold, when the program works, problems occur in one case, for instance, when recursively calling a function, while in the other case, under the same conditions, they don't. That's when you could draw a conclusion ... about the harm of freshly squeezed juice)))

[Ihor Herasko]

Vasiliy Sokolov #:

What does the stack have to do with it? In the first case, you tried to statically (at the compilation stage) allocate a large block of memory in the heap and the compiler deservedly kicked you in the head because it is not at all clear in the real world whether you can allocate so much memory or not.

In the second case you are allocating a large chunk of memory already in runtime. And it is immediately clear whether you can allocate it or not, because the program is already working with a specific resource of the machine (memory).

And what do pointers have to do with it? Arrays in mql are of two types, predefined at compile time and dynamic. Not only pointers *, but usual class fields can point to dynamic arrays as well. So using pointers here is absolutely not justified.

s.e. Strange impression of the code, like pointers, classes, macros - with complete lack of understanding of what's going on.

If we alter the example a bit, declare it locally and put a not so ugly number, the compiler tells us directly what the problem is:

#property strict
#define               ARRAY_SIZE           int(140000)

class Test
{
   
public:
   int               nA;
   double            fB;
   datetime          dtC;

                     Test(void)
                       : nA(0)
                       , fB(1.0)
                       , dtC(__DATETIME__)
                     {
                     };
};
 
void OnStart()
{
   Test classTest[ARRAY_SIZE];    // the size of local variables is too large
}

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