MQL5 Der Compiler unterscheidet nicht zwischen einer Klasse und einem Zeiger auf sie - Seite 11

 
Ilya Malev:

Diese hier: (* ) ist hier nicht erforderlich.

* wird im µl nur benötigt, wenn die Operationen =, ==, !=, !& oder || direkt auf den * Zeiger angewendet werden

IMHO ist das genau das, was Sie brauchen, damit Sie nicht vergessen, womit Sie es zu tun haben (ein Objekt oder einen Zeiger darauf).

Ilya Malev:

(Wenn Sie sie wieder entfernen und so tun wollen, als hätte es sie nie gegeben)))

Also, ja. Die weitere Entwicklung mit Zeigern wird zu einem vollständigen Klon von C++ führen.

Vielleicht werden sie in die Richtung von C# gehen, wo "verwalteter Code" keine Zeiger hat, sondern alles ein Objekt hat, sogar die üblichen Typen bool int double usw.

 
Ilya Malev:

Und übrigens kann es gut sein, dass, da alle offiziellen Kanäle (Forum, Hilfe, Dokumentation) über den Operator * schweigen, vielleicht die Admins darüber nachdenken, ihn wieder zu entfernen und so zu tun, als hätte er nie existiert))) Es ist also gefährlich, sich derzeit auf seine allgemeine Verwendung zu verlassen.

Das Schweigen liegt wahrscheinlich daran, dass 99,9 % der Nutzer sich nicht darum kümmern. Warum sollten sie ihr Gehirn mit unnötigen Informationen belasten? Und diejenigen, die sie brauchten, baten darum und bekamen sie.

Sie haben sich bis jetzt auch nicht um diese Funktion gekümmert, nicht wahr? Und jetzt fangen Sie verzweifelt an, Ausreden zu erfinden, warum Sie nichts davon wussten ;) Welchen Unterschied macht es, wann sie eingeführt wurde: sofort oder nach Monaten? Sie hätten immer noch nichts davon gewusst, wenn ich es Ihnen nicht gesagt hätte )

 

Hmmm... Vielleicht gibt es auch Zeiger auf das Array? Das muss ich mir mal ansehen... Ich vermisse sie so sehr...

 
Georgiy Merts:

Hmmm... Vielleicht gibt es auch Zeiger auf das Array? Das muss ich mir mal ansehen... Ich vermisse sie so sehr...

Nein. Man muss Arrays in Klassen unterbringen, sie haben Zeiger.

 
Ilya Baranov:

Nein. Man muss Arrays in Klassen unterbringen, sie haben Zeiger auf sie.

Ja, leider.

Eigentlich sind abgeleitete CArray-Klassen recht praktisch für mich. Das einzige, wofür ich Zeiger auf Arrays benötige, sind Indikatoren. Sie übergeben Referenzen auf Arrays, und ich muss diese Referenzen durch die gesamte Hierarchie der Objekte "ziehen", was sehr unbequem ist...

Ich habe einmal vorgeschlagen, entweder Zeiger auf Arrays zu machen oder eine Indikatorfunktion zu erstellen, die Zeiger auf Arrays der Standardbibliothek verwendet, anstatt Array-Links, aber leider wurde ich mit der Begründung abgelehnt, dass "wenn wir Zeiger auf Arrays zulassen, es möglich ist, nicht initialisierte Arrays zu verwenden", obwohl die Entwickler solche Ängste bei Objekten nicht haben... Nun ja, das überlasse ich ihrem Gewissen.

 
Georgiy Merts:

2) MQL muss nicht löschen, was es nicht ausgewählt hat. Dmitriy hatte oben recht - ein Objekt erstellen - es löschen. Ich mag die Praxis des "Müllsammlers" in C# nicht, wenn Objekte nicht gelöscht werden, wenn ich es will, sondern wenn der Sammler es will.

Der C#-Picker wird niemals ein lebendes Objekt oder einen Zeiger entfernen. Sein Zweck ist es, Müll aus dem Leichenhaufen zu entfernen und ihn manchmal zu defragmentieren.

 
Alexey Volchanskiy:

Niemals wird ein C#-Assembler ein lebendes Objekt oder einen Zeiger löschen. Sein Zweck ist es, Leichenmüll aus dem Heap zu entfernen und ihn manchmal zu defragmentieren.

Ich will damit nicht sagen, dass der Müllsammler ein lebendes Objekt oder einen Zeiger löschen wird. Was ich damit sagen will, ist, dass sie es löschen wird, wenn sie es will. Und das ist meiner Meinung nach nicht gut.

Ich kann mit oder ohne Löschung arbeiten. Und ich kann sogar Smartpoints machen... Dennoch bin ich der Meinung, dass die Löschung von Objekten möglich sein muss und dass die Person, die das Objekt erstellt hat, es löschen muss.

Das ist die Art von Old-School-Oldtimer, die ich bin.

 
SemenTalonov:

Wahrscheinlich werden sie in die Richtung von C# gehen, wo "verwalteter Code" keine Zeiger hat und alles ein Objekt hat, sogar einfache Typen bool int double, usw.

Ja, aber sie lassen immer noch die Möglichkeit, mit Zeigern in nicht verwaltetem Code zu arbeiten. Es stimmt, dass ein solcher Code Einschränkungen bei der Verbreitung unterliegt.

 
Georgiy Merts:

Ich will damit nicht sagen, dass der Müllsammler ein lebendes Objekt oder einen Zeiger löschen wird. Was ich damit sagen will, ist, dass sie es löschen wird, wenn sie es will. Und das ist meiner Meinung nach nicht gut.

Ich kann mit oder ohne Löschung arbeiten. Und ich kann sogar Smartpoints machen... Dennoch bin ich der Meinung, dass die Objekte gelöscht werden sollten, und zwar von demjenigen, der sie erstellt hat.

Das ist die Art von Old-School-Oldtimer, die ich bin.

Georges, geben Sie bitte ein Beispiel, ich verstehe Sie nicht. Ist es das, was Sie meinen? Ich schätze, Sie können selbst Smartpoints erstellen.

bool first = false;

int Foo()
{
  int i;
  if(!first)
  {
     first = true; 
     i = 123;
  }
  return i;   
}

// И ты будешь надеятся, что i сохранит свое значение между сотней вызовов Foo? Может да (очень редко, если Foo вызывается 100 раз подряд), а может и нет.
 
Alexey Volchanskiy:

Georges, gib mir bitte ein Beispiel, ich verstehe dich nicht. Ist es das, was Sie meinen? Es ist wahrscheinlich möglich, smartpoints selbst herzustellen.

Nein. Es ist klar, dass in diesem Fall die Variable beim Verlassen des Blocks gelöscht werden muss.

Ich spreche von Objekten, die von new erstellt wurden:

CMyObj* pmoObject  = new CMyObject;

Der C#-Standard spezifiziert: "Sowohl wertartige Objekte, wie z.B. Strukturen, als auch referenzartige Objekte, wie z.B. Klassen, werden automatisch zerstört, aber wertartige Objekte werden zerstört, wenn der Kontext, in dem sie enthalten sind, zerstört wird, während referenzartige Objekte vom Müllsammler auf unbestimmte Zeit zerstört werden, nachdem der letzte Verweis auf sie entfernt wurde."

Hier gefällt mir diese "unbestimmte Zeit" nicht. Obwohl ich sogar einräume, dass der Müllsammler ein Objekt viel effizienter löschen kann als ich, indem er das Objekt im Destruktor der Klasse löscht, die es erstellt hat.

Grund der Beschwerde: