Error del compilador con el parámetro de la plantilla = void* - página 5

[Ilya Malev]

Igor Makanu:

sólo a través de cadenas, solía utilizar StringConcatenate() para obtener la dirección del puntero, así:

No conocía el StringConcatenate, es una pena que en MT5 se haya rediseñado y no se pueda utilizar sin string s. Y StringFormat es mucho más rápido en el 4.

Y en general esta operación de "sondeo" del puntero a través de la cadena es dos veces más lenta en cinco, aunque en general todo es más rápido allí, a veces por un orden

[Alexey Navoykov]

fxsaber:

Los corchetes hacen que la expresión sea totalmente inequívoca.

¿Por qué esta falta de ambigüedad adicional, si un programador inteligente puede hacer todo sin ambigüedad? Y si seguimos con el espíritu del "compilador cuidadoso", entonces todas las expresiones en if deberían ir entre corchetes, por si un programador estúpido confunde algo.

Si se trata de una mayor claridad, basta con poner espacios:

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

[Alexey Navoykov]

pavlick_:

La utilidad de esta matriz es cuestionable, francamente. ¿Qué puede hacer con él? Sabes que no llamarás automáticamente a la eliminación de los miembros del array, ¿verdad?

¿Por qué? Los destructores de objetos son siempre virtuales

[pavlick_]

Alexey Navoykov:
¿Por qué? Los destructores de objetos son siempre virtuales.

Pruébalo. En caso de vacío* no hay ninguna posibilidad.

[Ilya Malev]

no se llama automáticamente a nadie).

Otra cosa es que no impida que el destructor del array recorra la lista y borre todos los objetos, si es necesario

aunque es más ventajoso utilizar un tipo base común y almacenar una referencia a él por muchas razones

[pavlick_]

Si quieres desechar CArayObject, tienes que hacer un wrapper (como este https://www.mql5.com/ru/forum/170952/page110#comment_9894796) sobre la clase base y ponerlos en un array (posiblemente el tuyo), pero entonces no necesitarás void*.

No estoy en contra del vacío*, es necesario, pero en una capacidad diferente.

[Alexey Navoykov]

pavlick_:

Pruébalo. En caso de vacío* no hay ninguna posibilidad.

Todo funciona bien, ¿por qué te lo inventas?

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;
  }

Lo tenemos en el registro:

void A::~A()
void B::~B()

De todas formas, ¿por qué caí en la trampa?

[fxsaber]

Alexey Navoykov:

¿Por qué esta falta de ambigüedad adicional, si un programador inteligente puede hacer todo sin ambigüedad? Y si seguimos con el espíritu del "compilador cuidadoso", entonces todas las expresiones en if deberían ir entre corchetes, por si un programador estúpido confunde algo.

Si se trata de mayor claridad, basta con poner espacios:

Si no quiere utilizar espacios para mayor claridad, bienvenido al mundo de los estilizadores.

[fxsaber]

Sobre los soportes adicionales

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;
}

[Alexey Navoykov]

fxsaber:

La visibilidad en los espacios no es nada: bienvenido al mundo de las herramientas de estilismo.

Si un estilizador hace que un código difícil de leer sea ilegible, entonces no se moleste con el estilizador.

Para mí, un estilista es bueno sólo cuando TODAS sus reglas pueden ser personalizadas con flexibilidad.