Bogue de compilation avec le paramètre template = void* - page 5

Nouveau commentaire
 
Igor Makanu:

uniquement à travers des chaînes, j'avais l'habitude d'utiliser StringConcatenate() pour obtenir l'adresse du pointeur, comme ceci :

Je ne connaissais pas StringConcatenate, c'est dommage que dans MT5 il a été remanié et ne peut pas être utilisé sans string s. Et StringFormat est beaucoup plus rapide sur 4.

Et en général, cette opération de "sondage" du pointeur à travers la chaîne est deux fois plus lente en cinq, bien que tout soit généralement plus rapide là-bas, parfois d'un ordre
 
fxsaber:

Les parenthèses rendent l'expression totalement dépourvue d'ambiguïté.

Et si nous continuons dans l'esprit du "compilateur bienveillant", alors toutes les expressions dans if devraient être entourées de crochets, au cas où un programmeur stupide confondrait quelque chose.

Si nous parlons d'une plus grande clarté, il suffit de mettre des espaces :

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

L'utilité d'un tel tableau est discutable, franchement. Que pouvez-vous en faire ? Vous savez que vous n'appellerez pas automatiquement la suppression sur les membres du tableau, n'est-ce pas ?

Pourquoi ? Les destructeurs d'objets sont toujours virtuels
 
Alexey Navoykov:
Pourquoi ? Les destructeurs d'objets sont toujours virtuels.

Essayez-le. En cas de nullité*, il n'y a aucune chance.

 

supprimer n'est pas du tout appelé automatiquement pour qui que ce soit).

De plus, cela n'empêche pas le destructeur du tableau de parcourir la liste et de supprimer tous les objets, si nécessaire.

bien qu'il soit plus avantageux d'utiliser un type de base commun et de stocker une référence à celui-ci pour de nombreuses raisons
 

Si vous voulez mettre CArayObject au rebut, vous devez faire une surcharge (comme ceci https://www.mql5.com/ru/forum/170952/page110#comment_9894796) sur la classe de base et les mettre dans un tableau (éventuellement le vôtre), mais alors vous n'aurez plus besoin de void*.

Je ne suis pas contre le vide*, il est nécessaire, mais dans une capacité différente.

 
pavlick_:

Essayez-le. En cas de nullité*, il n'y a aucune chance.

Tout fonctionne bien, pourquoi inventez-vous ça ?

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

On l'a dans le journal :

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

Pourquoi suis-je tombé dans le panneau de toute façon...

 
Alexey Navoykov:

Et si nous continuons dans l'esprit du "compilateur bienveillant", alors toutes les expressions dans if devraient être entourées de crochets, au cas où un programmeur stupide confondrait quelque chose.

Si l'on veut plus de clarté, il suffit de mettre des espaces :

Si vous voulez plus de clarté avec les espaces, vous devriez simplement mettre des espaces dans le code.

 
À propos des supports supplémentaires
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:

La visibilité sur les espaces n'est rien - bienvenue dans le monde des outils de stylisme.

Si un stylisateur rend illisible un code difficile à lire, il ne faut pas s'embêter avec le stylisateur.

Pour moi, un stylo n'est bon que si TOUTES ses règles peuvent être personnalisées avec souplesse.

123456789101112...20
Nouveau commentaire
Raison: