PLO. Application issues - page 3

[Yedelkin]

Technical reference. An example of a "wrapping mechanism" when working with classes (so you don't have to search for it):

https://www.mql5.com/ru/forum/3555/page3#comment_57315

[Yedelkin]

Question. The new operator. The Reference Manual states that new is an operator; however, in the examples, a check is often made after using this operator to make it equal to NULL. For instance:

//+------------------------------------------------------------------+
//| Создание фигуры                                                  |
//+------------------------------------------------------------------+
void CTetrisField::NewShape()
  {
   m_ypos=HORZ_BORDER;
//--- случайным образом создаём одну из 7 возможных фигур
   int nshape=rand()%7;
   switch(nshape)
     {
      case 0: m_shape=new CTetrisShape1; break;
      case 1: m_shape=new CTetrisShape2; break;
      case 2: m_shape=new CTetrisShape3; break;
      case 3: m_shape=new CTetrisShape4; break;
      case 4: m_shape=new CTetrisShape5; break;
      case 5: m_shape=new CTetrisShape6; break;
      case 6: m_shape=new CTetrisShape7; break;
     }
//--- отрисовываем
   if(m_shape!=NULL)
     {
      //--- начальные установки
      m_shape.SetRightBorder(WIDTH_IN_PIXELS+VERT_BORDER);
      m_shape.SetYPos(m_ypos);
      m_shape.SetXPos(VERT_BORDER+SHAPE_SIZE*8);
      //--- отрисуем
      m_shape.Draw();
     }
//---
  }

It is also said that"NULL can be compared to pointers to objects created using the new operator".

So it turns out that the new operator does not always create a new object? Or is checking for equality of a created object to NULL a peculiarity of a developer's style and is not obligatory?

[Mykola Demko]

Yedelkin:

Question. The new operator. The Reference Manual states that new is an operator; however, in the examples, a check is often made after using this operator to make it equal to NULL. For instance:

It is also said that"NULL can be compared to pointers to objects created using the new operator".

So it turns out that the new operator does not always create a new object? Or is checking for equality of a created object to NULL a peculiarity of a developer's style and is not obligatory?

If you create a dynamic object in one place of the program, it is logical that in another place you will destroy it, and it is not a fact that all this is within one function, hence a simple rule of thumb, before using a pointer to check whether it exists.

[Yedelkin]

Urain:
If you create a dynamic object in one place in a program, it is logical that you will destroy it in another place, and it is not certain that all this is within one function, so a simple rule is to check if it exists before using a pointer.

This is correct. But in the examples in the Reference Manual, the check is done immediately after the object is created, i.e. at one place in the program and within one function. And the rule given here is not quite on point. Why should the check be performed right after creation of an object?So it turns out that the new operator does not always create a new object? =(I repeat)=

Here is one more example among many:

//--- example for CArrayString::Add(string)
#include <Arrays\ArrayString.mqh>
//---
void OnStart()
  {
   CArrayString *array=new CArrayString;
   //---
   if(array==NULL)
     {
      printf("Object create error");
      return;
     } 

[Konstantin Gruzdev]

Yedelkin:

This is correct. But in the examples in the Reference Manual, the check is done immediately after the object is created, i.e. in one place in the program and within one function. And the above rule is not applicable here. Why should the check be performed right after the object is created?So it turns out that the new operator doesn't always create a new object (I repeat that)?

Here is one more example among many:

There is this possibility. In the help, the first paragraph.

[Yedelkin]

Lizar:
There is such a possibility. In the reference, the first paragraph.

OK. It turns out that operator behaviour is like a function. It may or may not create it.

[Rashid Umarov]

Yedelkin:
OK. It turns out that the operator's behaviour is that of a function. It may or may not be created.

For example, there is not enough memory for the object.

[Yedelkin]

Rosh:
For example, there wasn't enough memory for an object.

Sometimes a simple explanation helps to broaden your horizons considerably. Thank you!

[Yedelkin]

Question. After declaring a virtual function with a certain set of parameters and types in a parent class, is it possible to change the number and types of parameters of corresponding virtual functions in descendant classes?

On the one hand, the Reference Manual states that "a virtual function may be substituted in a derived class. The choice of which function definition to call for the virtual function is made dynamically (at runtime). A typical case is when a base class contains and derived classes have their own versions of that function". On the other hand, the examples given in the Reference Manual refer to cases where virtual functions have different function definition bodies rather than function definition headers .

[Ilyas]

Yedelkin:

Question. After declaring a virtual function with a certain set of parameters and their types in a parent class, is it possible to change the number and types of parameters of the corresponding virtual functions in the child classes?

Only an exact copy of the definition, except for default parameters (defaults may vary, but it is better not to use this)