Bug de compilador com parâmetro de modelo = vazio* - página 5

Novo comentário
 
Igor Makanu:

somente através de cordas, eu costumava usar StringConcatenate() para obter o endereço do ponteiro, desta forma:

Eu não sabia sobre StringConcatenate, é uma pena que no MT5 ele tenha sido redesenhado e não possa ser usado sem cordel s. E o StringFormat é muito mais rápido no 4.

E, em geral, esta operação de "sondagem" através de cordel é duas vezes mais lenta em cinco, embora geralmente tudo seja mais rápido lá, em alguns casos por uma ordem
 
fxsaber:

Os parênteses tornam a expressão completamente inequívoca.

E se continuarmos no espírito de "compilador cuidadoso", então todas as expressões em se devem ser incluídas entre parênteses, no caso de um programador estúpido misturar algo.

Se estamos falando de maior clareza, é suficiente colocar espaços:

a<<1 | b<<2 | c<<3
 
pavlick_:

A utilidade de um conjunto desse tipo é questionável, francamente. O que você pode fazer com ele? Você sabe que não vai chamar automaticamente os membros da matriz para excluir, certo?

Por quê? Os destruidores de objetos são sempre virtuais
 
Alexey Navoykov:
Por quê? Os destruidores de objetos são sempre virtuais.

Experimente. Em caso de vazio*, não há nenhuma chance.

 

não é chamado automaticamente para ninguém).

É outra coisa que não impede que o destruidor de matriz passe pela lista e apague todos os objetos, se necessário.

embora seja mais vantajoso usar um tipo de base comum e armazenar uma referência a ela por muitas razões
 

Se você quiser eliminar o CArayObject, você tem que fazer uma substituição (como esta https://www.mql5.com/ru/forum/170952/page110#comment_9894796) sobre a classe base e colocá-los em uma matriz (possivelmente sua), mas então você não precisará mais de vazio*.

Não sou contra o vazio*, ele é necessário, mas em uma capacidade diferente.

 
pavlick_:

Experimente. Em caso de vazio*, não há nenhuma chance.

Tudo está funcionando bem, por que você está inventando isso?

class B
{
 public: 
  ~B() { Print(__FUNCSIG__); }
};

class A
{
 public: 
  B b;
  ~A() { Print(__FUNCSIG__); }
};

void OnStart()
  {
   A* a= new A;
   
   void* p= a;
   delete p;
  }

Nós o obtemos no diário de bordo:

vazio A::~A()
vazio B::~B()

Por que caí nessa, de qualquer forma...

 
Alexey Navoykov:

E se continuarmos no espírito de "compilador cuidadoso", então todas as expressões em se devem ser incluídas entre parênteses, no caso de um programador estúpido misturar algo.

Se estamos falando de mais clareza, é suficiente colocar espaços:

Se você não quiser usar os espaços para maior clareza, bem-vindo ao mundo dos estilizadores.

 
Sobre os parênteses extras
class A
{
public:
  int i;
  
  A* GetPtr()
  {
    this.i = 1;
    
    return(&this);
  }
  
  void f()
  {
    Print(this.i);
  }
};

class B : public A
{
public:
  void* GetPtr()
  {
    this.i = 2;
    
    return(&this);
  }
};

void g( A* a)
{
  a.f();
}

void OnStart()
{    
  B* b = new B;
  
//   b.GetPtr().f(); // 'f' - member function not defined
  
  ((A*)b).GetPtr().f();   // 1
  ((A*)b.GetPtr()).f();   // 2
  ((A*)( b.GetPtr())).f(); // Доп. скобки, чтобы подчеркнуть, что именно имелось в виду, не полагаясь на приоритеты.

  delete b;
}
 
fxsaber:

A visibilidade nos espaços não é nada - bem-vindo ao mundo das ferramentas de modelagem.

Se um modelador torna um código difícil de ler ilegível, então não se preocupe com o modelador.

Para mim, um modelador só é bom quando TODAS as suas regras podem ser flexivelmente personalizadas.

123456789101112...20
Novo comentário