Preguntas sobre POO en MQL5 - página 82

 
Igor Makanu:

no importa qué inicializar, incluso int - cualquier número para llamar a este constructor

y elegí 0,0 para evitar errores de imprenta - cualquier dígito, es decir, 0,0. Es más difícil de escribir y de imprimir mal que 123

(doble)0

pero no así tampoco)))) acaba de mirar el código normalmente, todavía hay una manera de mirarlo anormalmente))
 
Alexandr Andreev:

(doble)0

no

Sólo escribo 0.0 - no se esperan otros números - ni siquiera hay una variable en el constructor

en general, como un estilo de autor de moda, tal vez no el mejor

 
Alexandr Andreev:

el punto no es la x) sino que puede haber un flotador en el receptor, y tampoco es fiable especificar 0,0

0.0 es un doble inequívoco para el compilador, float será 0.f
 
Vladimir Simakov:
0,0 es un doble inequívoco para el compilador, el float será 0,f

crédito)

 

Mientras la sección de "preguntas de más de 50 años" está abierta, permítanme interponer la mía en el tema de los calcos.

- ¿Cuáles son algunas formas de mejorar el código en términos de tolerancia a los fallos o de no redundancia?

- ¿Es necesaria la comprobaciónCheckPointer()!=POINTER_INVALID? ¿O definitivamente no es necesario? Explique por qué.

- Trayendo a no-const, para que sea posible llamar a métodos no-const. ¿Pueden llamarse los métodos no-const directamente en el método Compare ? es decir, deshacerse del resaltado amarillo const ?

#include <ChartObjects\ChartObjectsShapes.mqh>

class CChartObjectRectangleX : public CChartObjectRectangle
  {
public:

   void CChartObjectRectangleX(){};      
   virtual int       Compare(const CObject *node,const int mode=0) const 
   {
   CChartObjectRectangleX *n=NULL;
   const CChartObjectRectangleX*nc=dynamic_cast<const CChartObjectRectangleX*>(node);
   if(nc!=NULL)
   n=(CChartObjectRectangleX *) nc;
   if(n!=NULL) {
     if(mode==0) return CompareDate(n); 
     if(mode==1) return CompareValue(n); }return 0;    }
 
   virtual int       CompareDate( CChartObjectRectangleX *node) const { 
   //if(node!=NULL) 
      return (this.Time(1)-node.Time(1)); return 0;    }
    virtual int       CompareValue( CChartObjectRectangleX *node) const { 
   //if(node!=NULL) 
      return ((this.Price(1)-node.Price(1))*10/Point()); return 0;    }
};
 
Aleksey Mavrin:

Mientras la sección de "preguntas de más de 50 años" está abierta, permítanme interponer la mía en el tema de los calcos.

- ¿Cuáles son algunas formas de mejorar el código en términos de tolerancia a los fallos o de no redundancia?

- ¿Es necesaria la comprobación CheckPointer()!=POINTER_INVALID? ¿O definitivamente no es necesario? Explique por qué.

- Trayendo a no-const, para que sea posible llamar a métodos no-const. ¿Se puede llamar a los métodos no-const directamente en el método Compare? es decir, deshacerse del resaltado amarillo const?

class CChartObjectRectangleX : public CChartObjectRectangle
  {
public:
   virtual int       Compare(const CObject *node,const int mode=0) const
   {
   const CChartObjectRectangleX *n=dynamic_cast<const CChartObjectRectangleX*>(node);
   return !n?0: mode==0?CompareDate(n):CompareValue(n);}
   
   virtual int CompareDate(const CChartObjectRectangleX *node) const {return !node?0:int(Time(1)-node.Time(1));}
   virtual int CompareValue(const CChartObjectRectangleX *node) const {return !node?0:(int)MathRound(((Price(1)-node.Price(1))*10/Point()));}
};

Parece ser el mismo que el tuyo, sólo que con menos letras. Es cuestión de gustos, a quien le guste más, pero yo he eliminado la variable extra (el compilador probablemente la eliminaría también dentro del marco de optimización).

Con respecto a mi comprobación del nodo. Debe ser sustituido por CheckPointer(node)==POINTER_INVALID, pero es una sobrecarga - una llamada a la función. Incluso si está inline, al menos está desreferenciando y comprobando la bandera de estado. Si sólo la biblioteca o el hormigón, que ha escrito el programa utilizará métodos de comparación, mejor !nodo y en el código para vigilar el puntero no válido. Si eres demasiado perezoso para estar atento a los punteros o es una biblioteca para desvalidos, sólo CheckPointer(node)==POINTER_INVALID.

Si quitas el especificador const que has resaltado, no puedes llamar a estos métodos desde un objeto constante.

UPD: la comprobación resaltada se puede eliminar, ya que está en los métodos llamados.

 
Aleksey Mavrin:

Mientras la sección de "preguntas de más de 50 años" está abierta, permítanme interponer la mía en el tema de los elencos.

- ¿Cuáles son algunas formas de mejorar el código en términos de tolerancia a los fallos o de no redundancia?

- ¿Es necesaria la comprobación CheckPointer()!=POINTER_INVALID? ¿O definitivamente no es necesario? Explique por qué.

- Trayendo a no-const, para que sea posible llamar a métodos no-const. ¿Es posible llamar a un método no-const directamente en el método Compare ? es decir, para deshacerse del resaltado amarillo const ?

La idea es escribir dos métodos de la misma función con y sin el cuerpo const - por decirlo suavemente - no vale la pena))))

Pero la probabilidad de encontrar dos métodos es cercana a cero.... Porque la posibilidad de existencia deCChartObjectRectangle:: Price- sin const en el cuerpo - creo que es poco probable.

La llamada de esta función desde el exterior no tiene ningún efecto. Es decir, la const funciona sólo con funciones internas y se asegura de que no se ha escrito nada en la memoria del objeto (no ha cambiado el valor de la variable). En otras palabras, no puedes llamar a Set(a) durante la const... A menudo, en alguna confusión, para asegurarse de que esta función no sobrescribe nada, se puede establecer rápidamente estos consts (aunque esto es probablemente mi supresión).

Considera que los consts deben ser empujados justo en cualquier lugar sin llegar a )))) para que sea más fácil comprobar algo más tarde.


¿Necesita CheckPointer()!=POINTER_INVALID una comprobación?

Y por qué no.... hacer un bool Check(<template> &T) { retun CheckPointer(T)!=POINTER_INVALID } El compilador debe hacerlo lo más simple posible. Y se verá aún mejor.

Es más rápido.

int a[1000];
for (int i=0; i<ArraySize(a); i++)....
или
for (int i=ArraySize(a); i>=0; i--)....
дак вот разницы не должно быть вообще


Bueno, no he cambiado mucho.

template<typename T>
bool Check(T *a) {return CheckPointer(a)!=POINTER_INVALID;};

class CChartObjectRectangleX : public CChartObjectRectangle
  {
  #define  ME CChartObjectRectangleX
public:
   void ME(){};      
   virtual int       Compare(const CObject *node,const int mode=0) const 
   {
   const ME*nc=dynamic_cast<const ME*>(node);
   return Check(nc)?mode==0?CompareDate(nc):CompareValue(nc):0;
   } 
   virtual int       CompareDate(const ME *node) const            {return (this.Time(1)-node.Time(1));}
   virtual int       CompareValue(const ME *node) const           {return ((this.Price(1)-node.Price(1))*10/Point()); }
 #undef  ME
};

Este es todo su código.

 
Vladimir Simakov:

Parece ser el mismo que el tuyo, sólo que con menos letras. Así que, es cuestión de gustos, pero he eliminado la variable extra (lo más probable es que el compilador la haya eliminado como parte de la optimización).

Con respecto a mi comprobación del nodo. Debe ser sustituido por CheckPointer(node)==POINTER_INVALID, pero es una sobrecarga - una llamada a la función. Incluso si está inline, al menos está desreferenciando y comprobando la bandera de estado. Si sólo la biblioteca o el hormigón, que ha escrito el programa utilizará métodos de comparación, mejor !nodo y en el código para vigilar el puntero no válido. Si eres demasiado perezoso para estar atento a los punteros o es una biblioteca para desvalidos, sólo CheckPointer(node)==POINTER_INVALID.

Si eliminas el especificador const, no puedes llamar a estos métodos desde un objeto constante.

me ha costado mucho abrir la pestaña


Supongo que 4 años de universidad no aportaron mucho a mis conocimientos (la explicación se queda atrás en la basura).

 

la variante sin la constitución ya que la clase base no tiene referencia a los parámetros de entrada también funcionará correctamente, aunque no es un estilo muy inteligente

#include <ChartObjects\ChartObjectsShapes.mqh>

template<typename T>
bool Check(T *a) {return CheckPointer(a)!=POINTER_INVALID;};

class CChartObjectRectangleX : public CChartObjectRectangle
  { #define  ME CChartObjectRectangleX
public: 
   void ME(){};      
   virtual int       Compare(CObject *node,int mode=0) 
   {
   ME*nc=dynamic_cast<ME*>(node);
   return Check(nc)?mode==0?CompareDate(nc):CompareValue(nc):0;
   } 
   virtual int       CompareDate(ME *node)             {return (this.Time(1)-node.Time(1));}
   virtual int       CompareValue(ME *node)            {return ((this.Price(1)-node.Price(1))*10/Point()); }
 #undef  ME
};
 

También una variante del mismo código.

template<typename T>
bool Check(T *a) {return CheckPointer(a)!=POINTER_INVALID;};

class CChartObjectRectangleX : public CChartObjectRectangle
  { #define  ME CChartObjectRectangleX
public: 
   void ME(){};      
   virtual int       Compare(CObject *node,int mode=0)      {return Check(node)?mode==0?CompareDate(node):CompareValue(node):0;} 
   virtual int       CompareDate(CObject *node)             {return (  Time(1)-dynamic_cast<ME*>(node).Time(1));}
   virtual int       CompareValue(CObject *node)            {return ((Price(1)-dynamic_cast<ME*>(node).Price(1))*10/Point()); }
 #undef  ME
};


Es el mismo con las contras.

template<typename T>
bool Check(T *a) {return CheckPointer(a)!=POINTER_INVALID;};

class CChartObjectRectangleX : public CChartObjectRectangle
  { #define  ME CChartObjectRectangleX
public: 
   void ME(){};      
   virtual int       Compare(CObject const *node,int const mode=0)   const{return Check(node)?mode==0?CompareDate(node):CompareValue(node):0;} 
   virtual int       CompareDate(CObject const *node)                const{return (  Time(1)-dynamic_cast<const ME*>(node).Time(1));}
   virtual int       CompareValue(CObject const *node)               const{return ((Price(1)-dynamic_cast<const ME*>(node).Price(1))*10/Point()); }
 #undef  ME
};
Razón de la queja: