OLP. Questões de aplicação - página 3

[Yedelkin]

Referência técnica. Um exemplo de um "mecanismo de embrulho" quando se trabalha com aulas (para não ter de o procurar):

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

[Yedelkin]

Pergunta. O novo operador. O Manual de Referência afirma que o novo é um operador; no entanto, nos exemplos, é frequentemente feita uma verificação após a utilização deste operador para o tornar igual ao NULL. Por exemplo:

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

Diz-se também que"NULL pode ser comparado a apontadores para objectos criados utilizando o novo operador".

Então, acontece que o novo operador nem sempre cria um novo objecto? Ou a verificação da igualdade de um objecto criado à NULL é uma peculiaridade do estilo de um criador e não é obrigatória?

[Mykola Demko]

Yedelkin:

Pergunta. O novo operador. O Manual de Referência afirma que o novo é um operador; no entanto, nos exemplos, é frequentemente feita uma verificação após a utilização deste operador para garantir que é igual ao NULL. Por exemplo:

Diz-se também que"NULL pode ser comparado a apontadores para objectos criados utilizando o novo operador".

Então, acontece que o novo operador nem sempre cria um novo objecto? Ou a verificação da igualdade de um objecto criado à NULL é uma peculiaridade do estilo de um criador e não é obrigatória?

Se criar um objecto dinâmico num lugar do programa, é lógico que noutro lugar o destrua, e não é um facto que tudo isto esteja dentro de uma função, daí uma simples regra de ouro, antes de utilizar um ponteiro para verificar se ele existe.

[Yedelkin]

Urain:
Se criar um objecto dinâmico num lugar num programa, é lógico que o destrua noutro lugar, e não é certo que tudo isto esteja dentro de uma função, por isso uma regra simples é verificar se ele existe antes de utilizar um ponteiro.

Isto é correcto. Mas nos exemplos do Manual de Referência, a verificação é feita imediatamente após a criação do objecto, ou seja, num lugar do programa e dentro de uma função. E a regra aqui dada não é bem a questão. Porque é que a verificação deve ser efectuada logo após a criação de um objecto?Então, acontece que o novo operador nem sempre cria um novo objecto? =(Repito)=

Aqui está mais um exemplo entre muitos:

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

Isto é correcto. Mas nos exemplos do Manual de Referência, a verificação é feita imediatamente após a criação do objecto, ou seja, num lugar do programa e dentro de uma função. E a regra acima não é aplicável aqui. Porque deve a verificação ser efectuada logo após a criação do objecto?Então, acontece que o novo operador nem sempre cria um novo objecto (repito isto)?

Aqui está mais um exemplo entre muitos:

Existe esta possibilidade. Na ajuda, o primeiro parágrafo.

[Yedelkin]

Lizar:
Essa possibilidade existe. Na referência, o primeiro parágrafo.

OK. Acontece que o comportamento do operador é como o de uma função. Pode ou não criá-lo.

[Rashid Umarov]

Yedelkin:
OK. Acontece que o comportamento do operador é o de uma função. Pode ou não ser criado.

Por exemplo, não há memória suficiente para o objecto.

[Yedelkin]

Rosh:
Por exemplo, não havia memória suficiente para um objecto.

Por vezes uma simples explicação ajuda a alargar consideravelmente os seus horizontes. Obrigado!

[Yedelkin]

Pergunta. Uma vez declarada uma função virtual com um conjunto específico de parâmetros e tipos numa classe parental, o número e os tipos de parâmetros das funções virtuais correspondentes podem ser alterados nas classes infantis?

Por um lado, o Manual de Referência afirma que "uma função virtual pode ser substituída numa classe derivada ". A escolha da definição da função a chamar para a função virtual é feita de forma dinâmica (em tempo de execução). Um caso típico é quando uma classe base contém e as classes derivadas têm as suas próprias versões dessa função". Por outro lado, os exemplos dados no Manual de Referência referem-se a casos em que as funções virtuais têm corpos de definição de funções diferentes em vez de cabeçalhos de definição de funções.

[Ilyas]

Yedelkin:

Pergunta. Após declarar uma função virtual com um determinado conjunto de parâmetros e os seus tipos numa classe parental, é possível alterar o número e os tipos de parâmetros das funções virtuais correspondentes nas classes infantis?

Apenas uma cópia exacta da definição, excepto para os parâmetros por defeito (os valores por defeito podem variar, mas é melhor não os utilizar)