OLP. Problemas de aplicación - página 3

[Yedelkin]

Referencia técnica. Un ejemplo de "mecanismo de envoltura" al trabajar con clases (para no tener que buscarlo):

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

[Yedelkin]

Pregunta. El nuevo operador. El Manual de Referencia indica que new es un operador; sin embargo, en los ejemplos, a menudo se hace una comprobación después de usar este operador para hacerlo igual a NULL. Por ejemplo:

//+------------------------------------------------------------------+
//| Создание фигуры                                                  |
//+------------------------------------------------------------------+
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();
     }
//---
  }

También se dice que"NULL puede compararse con punteros a objetos creados con el operador new".

Entonces, ¿resulta que el operador new no siempre crea un objeto nuevo? ¿O la comprobación de la igualdad de un objeto creado a NULL es una peculiaridad del estilo de un desarrollador y no es obligatoria?

[Mykola Demko]

Yedelkin:

Pregunta. El nuevo operador. El Manual de Referencia indica que new es un operador; sin embargo, en los ejemplos, a menudo se hace una comprobación después de usar este operador para hacerlo igual a NULL. Por ejemplo:

También se dice que"NULL puede compararse con punteros a objetos creados con el operador new".

Entonces, ¿resulta que el operador new no siempre crea un objeto nuevo? ¿O la comprobación de la igualdad de un objeto creado a NULL es una peculiaridad del estilo de un desarrollador y no es obligatoria?

Si creas un objeto dinámico en un lugar del programa, es lógico que en otro lugar lo destruyas, y no es un hecho que todo esto esté dentro de una función, de ahí una simple regla general, antes de usar un puntero comprobar si existe.

[Yedelkin]

Urain:
Si se crea un objeto dinámico en un lugar de un programa, es lógico que se destruya en otro lugar, y no es seguro que todo esto esté dentro de una función, por lo que una regla sencilla es comprobar si existe antes de utilizar un puntero.

Esto es correcto. Pero en los ejemplos del Manual de Referencia, la comprobación se realiza inmediatamente después de la creación del objeto, es decir, en un lugar del programa y dentro de una función. Y la regla que se da aquí no es del todo acertada. ¿Por qué debe realizarse la comprobación justo después de la creación de un objeto?Entonces, ¿resulta que el operador new no siempre crea un objeto nuevo? =(repito)=

He aquí un ejemplo más entre muchos otros:

//--- 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:

Esto es correcto. Pero en los ejemplos del Manual de Referencia, la comprobación se realiza inmediatamente después de la creación del objeto, es decir, en un lugar del programa y dentro de una función. Y la regla anterior no es aplicable aquí. ¿Por qué debe realizarse la comprobación justo después de la creación del objeto?Entonces, ¿resulta que el operador new no siempre crea un nuevo objeto (lo repito)?

He aquí un ejemplo más entre muchos otros:

Existe esta posibilidad. En la ayuda, el primer párrafo.

[Yedelkin]

Lizar:
Existe esa posibilidad. En la referencia, el primer párrafo.

DE ACUERDO. Resulta que el comportamiento del operador es como el de una función. Puede o no crearlo.

[Rashid Umarov]

Yedelkin:
DE ACUERDO. Resulta que el comportamiento del operador es el de una función. Puede que se cree o no.

Por ejemplo, no hay suficiente memoria para el objeto.

[Yedelkin]

Rosh:
Por ejemplo, no había suficiente memoria para un objeto.

A veces una simple explicación ayuda a ampliar considerablemente los horizontes. Gracias.

[Yedelkin]

Pregunta. Una vez declarada una función virtual con un conjunto específico de parámetros y tipos en una clase madre, ¿puede modificarse el número y los tipos de parámetros de las funciones virtuales correspondientes en las clases derivadas?

Por un lado, el Manual de Referencia afirma que "una función virtual puede ser sustituida en una clase derivada . Laelección de ladefinición de la función a la que se llama para la función virtual se hace de forma dinámica (en tiempo de ejecución). Un caso típico es cuando una clase base contiene y las clases derivadas tienen sus propias versiones de esa función". Por otra parte, los ejemplos que se dan en el Manual de referencia se refieren a casos en los que las funciones virtuales tienen cuerpos de definición de funciones diferentes y no cabeceras de definición de funciones.

[Ilyas]

Yedelkin:

Pregunta. Después de declarar una función virtual con un determinado conjunto de parámetros y sus tipos en una clase padre, ¿es posible cambiar el número y los tipos de parámetros de las funciones virtuales correspondientes en las clases hijas?

Sólo una copia exacta de la definición, excepto los parámetros por defecto (los valores por defecto pueden variar, pero es mejor no usar esto)