Compilerfehler mit Template-Parameter = void* - Seite 5

Neuer Kommentar
 
Igor Makanu:

nur durch Zeichenketten, habe ich StringConcatenate() verwendet, um Zeigeradressen zu erhalten, etwa so:

Ich wusste nichts von StringConcatenate, es ist schade, dass es in MT5 umgestaltet wurde und nicht ohne String s verwendet werden kann. Und StringFormat ist viel schneller auf 4.

Und im Allgemeinen ist dieser Vorgang des "Abfragens" des Zeigers durch die Zeichenkette zweimal langsamer in fünf, obwohl dort im Allgemeinen alles schneller ist, manchmal um eine Ordnung
 
fxsaber:

Klammern machen den Ausdruck völlig unzweideutig.

Warum diese zusätzliche Eindeutigkeit, wenn ein kluger Programmierer alles eindeutig machen kann? Und wenn wir im Sinne des "fürsorglichen Compilers" weitermachen, dann sollten alle Ausdrücke in if in geschweifte Klammern eingeschlossen werden, für den Fall, dass ein dummer Programmierer etwas durcheinanderbringt.

Wenn es um mehr Klarheit geht, genügt es, Leerzeichen zu setzen:

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

Die Nützlichkeit einer solchen Anordnung ist, offen gesagt, fraglich. Was kann man damit machen? Sie wissen, dass Sie bei Array-Mitgliedern nicht automatisch das Löschen aufrufen, oder?

Warum? Objektdestruktoren sind immer virtuell.
 
Alexey Navoykov:
Warum? Objektdestruktoren sind immer virtuell.

Versuchen Sie es. Im Falle der Nichtigkeit* gibt es überhaupt keine Chance.

 

löschen wird für niemanden automatisch aufgerufen).

Eine andere Sache ist, dass es den Array-Destruktor nicht daran hindert, die Liste durchzugehen und alle Objekte zu löschen, falls nötig

obwohl es aus vielen Gründen vorteilhafter ist, einen gemeinsamen Basistyp zu verwenden und einen Verweis auf ihn zu speichern
 

Wenn Sie CArayObject abschaffen wollen, müssen Sie einen Override (wie diesen https://www.mql5.com/ru/forum/170952/page110#comment_9894796) über die Basisklasse machen und sie in ein Array (möglicherweise Ihres) legen, aber dann brauchen Sie kein void* mehr.

Ich bin nicht gegen die Leere*, sie ist notwendig, aber in einer anderen Funktion.

 
pavlick_:

Versuchen Sie es. Im Falle der Nichtigkeit* besteht überhaupt keine Chance.

Alles funktioniert einwandfrei, warum denken Sie sich das aus?

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

Wir bekommen es im Protokoll:

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

Warum bin ich überhaupt darauf hereingefallen...

 
Alexey Navoykov:

Warum diese zusätzliche Eindeutigkeit, wenn ein kluger Programmierer alles eindeutig machen kann? Und wenn wir im Sinne des "fürsorglichen Compilers" weitermachen, dann sollten alle Ausdrücke in if in geschweifte Klammern eingeschlossen werden, sonst kann ein dummer Programmierer durcheinander kommen.

Wenn es um mehr Klarheit geht, genügt es, Leerzeichen zu setzen:

Wenn Sie keine Leerzeichen zur Verdeutlichung verwenden möchten, heißen wir Sie in der Welt der Stilisierer willkommen.

 
Über die zusätzlichen Klammern
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:

Die Sichtbarkeit von Zwischenräumen ist nichts - willkommen in der Welt der Styling-Tools.

Wenn ein Styler einen schwer lesbaren Code unlesbar macht, sollten Sie sich nicht um den Styler kümmern.

Für mich ist ein Styler nur dann gut, wenn ALLE seine Regeln flexibel angepasst werden können.

123456789101112...20
Neuer Kommentar