OLP. Problemi di applicazione - pagina 3

[Yedelkin]

Riferimento tecnico. Un esempio di "meccanismo di avvolgimento" quando si lavora con le classi (per non doverlo cercare):

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

[Yedelkin]

Domanda. Il nuovo operatore. Il manuale di riferimento afferma che new è un operatore; tuttavia, negli esempi, viene spesso fatto un controllo dopo aver usato questo operatore per assicurarsi che sia uguale a NULL. Per esempio:

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

Si dice anche che"NULL può essere paragonato a puntatori a oggetti creati utilizzando l'operatore new".

Quindi si scopre che il nuovo operatore non crea sempre un nuovo oggetto? O il controllo dell'uguaglianza di un oggetto creato a NULL è una peculiarità dello stile di uno sviluppatore e non è obbligatorio?

[Mykola Demko]

Yedelkin:

Domanda. Il nuovo operatore. Il Manuale di riferimento afferma che new è un operatore; tuttavia, negli esempi, viene spesso fatto un controllo dopo aver usato questo operatore per assicurarsi che sia uguale a NULL. Per esempio:

Si dice anche che"NULL può essere paragonato a puntatori a oggetti creati utilizzando l'operatore new".

Quindi si scopre che il nuovo operatore non crea sempre un nuovo oggetto? O il controllo dell'uguaglianza di un oggetto creato a NULL è una peculiarità dello stile di uno sviluppatore e non è obbligatorio?

Se si crea un oggetto dinamico in un posto del programma, è logico che in un altro posto lo si distrugga, e non è un fatto che tutto questo sia all'interno di una funzione, da qui una semplice regola empirica, prima di usare un puntatore per controllare se esiste.

[Yedelkin]

Urain:
Se si crea un oggetto dinamico in un posto in un programma, è logico che lo si distrugga in un altro posto, e non è certo che tutto questo sia all'interno di una funzione, quindi una semplice regola è controllare se esiste prima di usare un puntatore.

Questo è corretto. Ma negli esempi del Manuale di riferimento, il controllo viene fatto immediatamente dopo la creazione dell'oggetto, cioè in un punto del programma e all'interno di una funzione. E la regola data qui non è del tutto pertinente. Perché il controllo dovrebbe essere eseguito subito dopo la creazione di un oggetto?Quindi si scopre che il nuovo operatore non crea sempre un nuovo oggetto? =(ripeto)=

Ecco un altro esempio tra i tanti:

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

Questo è corretto. Ma negli esempi del Manuale di riferimento, il controllo viene fatto immediatamente dopo la creazione dell'oggetto, cioè in un punto del programma e all'interno di una funzione. E la regola di cui sopra non è applicabile in questo caso. Perché il controllo dovrebbe essere eseguito subito dopo la creazione dell'oggetto?Quindi risulta che il nuovo operatore non crea sempre un nuovo oggetto (lo ripeto)?

Ecco un altro esempio tra i tanti:

C'è questa possibilità. Nella guida, il primo paragrafo.

[Yedelkin]

Lizar:
Esiste una tale possibilità. Nel riferimento, il primo paragrafo.

OK. Si scopre che il comportamento dell'operatore è come quello di una funzione. Può crearlo o meno.

[Rashid Umarov]

Yedelkin:
OK. Si scopre che il comportamento dell'operatore è quello di una funzione. Può essere creato o meno.

Per esempio, non c'è abbastanza memoria per l'oggetto.

[Yedelkin]

Rosh:
Per esempio, non c'era abbastanza memoria per un oggetto.

A volte una semplice spiegazione aiuta ad allargare considerevolmente gli orizzonti. Grazie!

[Yedelkin]

Domanda. Una volta che una funzione virtuale con un insieme specifico di parametri e tipi è dichiarata in una classe madre, il numero e i tipi di parametri delle funzioni virtuali corrispondenti possono essere cambiati nelle classi derivate?

Da un lato, il Manuale di Riferimento afferma che "una funzione virtuale può essere sostituita in una classe derivata . Lascelta di quale definizione di funzione chiamare per la funzione virtuale è fatta dinamicamente (a runtime). Un caso tipico è quando una classe base contiene e le classi derivate hanno le proprie versioni di quella funzione". D'altra parte, gli esempi forniti nel Manuale di riferimento si riferiscono a casi in cui le funzioni virtuali hanno corpi di definizione di funzione differenti piuttosto che intestazioni di definizione di funzione.

[Ilyas]

Yedelkin:

Domanda. Dopo aver dichiarato una funzione virtuale con un certo insieme di parametri e i loro tipi in una classe padre, è possibile cambiare il numero e i tipi di parametri delle funzioni virtuali corrispondenti nelle classi figlie?

Solo una copia esatta della definizione, tranne che per i parametri predefiniti (i valori predefiniti possono variare, ma è meglio non usare questo)