Perguntas sobre OOP em MQL5 - página 82

Novo comentário
 
Igor Makanu:

não importa o que inicializar lá, mesmo int - qualquer número para chamar este construtor em particular

e escolhi 0,0 para evitar erros de impressão - qualquer dígito, ou seja, 0,0. É mais difícil escrever e imprimir mal do que 123

(duplo)0

mas também não assim)))) só agora olhou para o código normalmente, ainda há uma maneira de olhar para ele de forma anormal))
 
Alexandr Andreev:

(duplo)0

não

Eu só escrevo 0,0 - não são esperados outros números - não há sequer uma variável no construtor

em geral, como um estilo de autor da moda, talvez não seja o melhor

 
Alexandr Andreev:

o ponto não é o x) mas que pode haver um flutuador no receptor, e também não é confiável especificar 0,0

0,0 é um duplo inequívoco para o compilador, o flutuador será 0,f
 
Vladimir Simakov:
0,0 é duplo inequívoco para o compilador, o flutuador será 0,f

crédito)

 

Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.

- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?

- É necessário oCheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.

- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. Os métodos não-constritivos podem ser chamados diretamente no método Comparar ? ou seja, se livrar do amarelo destacado 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:

Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.

- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?

- É necessário o CheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.

- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. Os métodos não-constritivos podem ser chamados diretamente no método Comparar ? ou seja, se livrar do amarelo destacado 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()));}
};

É mais ou menos o mesmo que o seu, só que com menos letras. É uma questão de gosto, quem gosta mais, mas eu removi a variável extra (muito provavelmente teria sido removida pelo compilador dentro da estrutura de otimização).

A respeito da minha verificação do !nó. Deve ser substituído por CheckPointer(node)==POINTER_INVALID, mas é uma sobrecarga - uma chamada de função. Mesmo que seja alinhada, ainda assim é pelo menos desreferenciada e verificada a bandeira de status. Se apenas biblioteca ou concreto, você escreveu um programa de comparação de métodos, melhor !nodo e em código para observar o ponteiro inválido. Se você é preguiçoso demais para ficar atento aos ponteiros ou se é uma biblioteca para os pontos fracos, apenas CheckPointer(node)==POINTER_INVALID.

Se você remover o especificador constante que você destacou, não poderá chamar estes métodos de um objeto constante.

UPD: a verificação destacada pode ser removida, pois está nos chamados métodos.

 
Aleksey Mavrin:

Enquanto a seção "perguntas acima de 50" está aberta, deixem-me interjetar minhas próprias perguntas no assunto de fundições.

- Quais são algumas maneiras de melhorar o código em termos de tolerância a falhas ou não-redundância?

- É necessário o CheckPointer()!=POINTER_INVALID check? Ou definitivamente não é necessário? Explique por quê.

- Trazer a não-constrição, para que seja possível chamar de métodos não-constritivos. É possível chamar um método não-constante diretamente no método Comparar ? ou seja, para se livrar do amarelo destacado const ?

A idéia é escrever dois métodos da mesma função com e sem o corpo constante - para dizer de forma suave - não vale a pena))))

Mas a probabilidade de encontrar dois métodos é próxima de zero.... Porque a possibilidade de existência doCChartObjectRectangle::Preço - sem constância no corpo - acho que é improvável.

A chamada desta função do exterior não tem nenhum efeito. Isto é, o const funciona apenas com funções internas e garante que nada foi escrito na memória do objeto (não alterou o valor da variável). Em outras palavras, não se pode chamar Set(a) durante a const... Muitas vezes, em alguma confusão, para ter certeza de que esta função não sobrescreva nada, você pode organizar rapidamente estas consignações (embora esta seja provavelmente minha eliminação).

Considere que os consignatários devem ser empurrados apenas para todos os lugares sem obter)))) para facilitar a verificação posterior de algo.


O CheckPointer()!=POINTER_INVALID precisa de um cheque?

E porque não.... fazer um CheckPointer(T) { retun CheckPointer(T)!=POINTER_INVALID } O compilador deve torná-lo o mais simples possível. E vai ficar ainda melhor.

É mais rápido.

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


Bem, eu não mudei muito.

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 é todo o seu código.

 
Vladimir Simakov:

Parece ser o mesmo que o seu, só que com menos letras. Portanto, é uma questão de gosto, mas eu removi a variável extra (muito provavelmente, o compilador a teria removido como parte da otimização).

A respeito da minha verificação do !nó. Deve ser substituído por CheckPointer(node)==POINTER_INVALID, mas é uma sobrecarga - uma chamada de função. Mesmo que seja alinhada, ainda assim é pelo menos desreferenciada e verificada a bandeira de status. Se apenas biblioteca ou concreto, você escreveu um programa de comparação de métodos, melhor !nodo e em código para observar o ponteiro inválido. Se você é preguiçoso demais para ficar atento aos ponteiros ou se é uma biblioteca para os pontos fracos, apenas CheckPointer(node)==POINTER_INVALID.

Se você remover o especificador constante, não poderá chamar estes métodos de um objeto constante.

demorei muito tempo para abrir a aba


Acho que 4 anos de faculdade não acrescentaram muito ao meu conhecimento (a explicação está ficando para trás no lixo).

 

a variante sem a constituição já que a classe base não tem referência aos parâmetros de entrada também funcionará corretamente, embora este não seja um estilo muito 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
};
 

Também uma variante do mesmo 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
};


É o mesmo com os 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
};
1...757677787980818283848586878889...96
Novo comentário