Merkmale der Sprache mql5, Feinheiten und Techniken - Seite 211

Neuer Kommentar
 
fxsaber #:

Sie selbst haben den 4. Fehler gemeldet. Warum ist ZeroMemory schlechter als {} ? D.h. wir haben einen nicht autorisierten Mechanismus für den Zugriff auf private Daten, der vom Compiler aus irgendeinem Grund nicht erkannt wird.

Rechnen Sie damit, dass die Entwickler das Problem nicht beheben werden? Früher hat der Compiler auchnicht aufZeroMemory reagiert

 
A100 #:

Sie selbst haben den 4. Fehler gemeldet. Warum ist ZeroMemory schlechter als {} ? D.h. wir haben einen unautorisierten Mechanismus für den Zugriff auf Private, den der Compiler aus irgendeinem Grund nicht erkennen kann.

Ich glaube nicht, dass es ein Fehler ist. Die Struktur hat keinen Konstruktor, aber sie wird initialisiert. FileReadStruct - das ist eine wirklich beängstigende Sache...

 
fxsaber #:

Ich sehe das nicht als Fehler an. Die Struktur hat keinen Konstruktor, sie wird initialisiert. FileReadStruct ist also eine ziemlich beängstigende Sache.

uint  FileReadStruct( 
   int          file_handle,        // handle файла 
   const void&  struct_object,      // структура, куда происходит считывание 
   int          size=-1             // размер структуры в байтах 
   );

Nach der Beschreibung zu urteilen, handelt es sich um eine Art Selbstbetrug

 
A100 #:

Der Beschreibung nach klingt es nach einer Art Selbstbetrug.

Nun, ja - es ist alles Täuschung.

 
A100 #:

Der Beschreibung nach zu urteilen, handelt es sich um eine Art Selbstzerstörung

Verweis auf die Dokumentation ohne Berücksichtigung von Copy-Paste-Artefakten - seltsam.

 
fxsaber #:

Links zur Dokumentation ohne Rücksicht auf Copy-Paste-Artefakte - seltsam.

Ich sehe diese Funktion zum ersten Mal überhaupt - sie hätten mich darauf hinweisen können, dass es einen Fehler in der Beschreibung gibt

Neben der Beschreibung liegt auch ein struktureller Fehler vor:

struct X {
    X( int i ) : i( i ) {}
    const int i;
};
void OnStart()
{
    X x( 5 );
    FileReadStruct( 0, x, -1 ); //(1) нормально ???
    ZeroMemory( x );            //(2) Error: 'x' - not allowed for objects with protected members or inheritance
}

Warum ist ZeroMemory schlechter als FileReadStruct?

Eine weitere Hoffnung, dass die Entwickler es nicht bemerken, es aufschieben oder zu faul sind, es zu beheben (um den Punkt zu unterstreichen)?

Mein Argument ist einfach: ZeroMemory wurde einmal mit all diesen Funktionen (einschließlich der privaten ) kompiliert, aber sie haben es bemerkt, sie haben es in den Griff bekommen und es behoben.

 
A100 #:

Das ist das erste Mal, dass ich diese Funktion sehe - man hätte mir sagen können, dass es einen Fehler in der Beschreibung gibt.

Ich habe mir die Beschreibung dieser Funktion nie angesehen. Der Name verrät es bereits.

Neben der Beschreibung gibt es auch einen strukturellen Fehler:

Der folgende Code enthält keinen Fehler.

struct MqlTick2 : private MqlTick {};

void OnStart()
{
  MqlTick2 Ticks[4] = {};

  uchar Bytes[];
  
  StructToCharArray(Ticks[0], Bytes);
  CharArrayToStruct(Ticks[1], Bytes);

  FileReadStruct(0, Ticks[0]);
  FileWriteStruct(0, Ticks[1]);
  
  FileWriteArray(0, Ticks);
  FileReadArray(0, Ticks);
}

Die Langeweile wird nicht über die Bequemlichkeit siegen!


Warum ist ZeroMemory schlechter als FileReadStruct?

Sie verweisen gerne auf die Dokumentation. Hier steht alles über die Grenzen von ZeroMemory. Es wird jedoch nichts über die Einschränkungen von File* gesagt. Was ZeroMemory betrifft, so urteile ich nach dem, was ich habe. Das ist jetzt nicht praktisch, aber es scheint absichtlich so gemacht worden zu sein.

Vergleicht man jedoch diese beiden Funktionen, so arbeitet FileReadStruct nur mit einfachen Strukturen. Dies ist ein grundlegender Unterschied.


In diesem Thema geht es um die Eigenheiten von MQL5. Ich habe auf eine hingewiesen (sie funktioniert nicht in MQL4). Dieser Dialog ist leider reine Zeitverschwendung

 
fxsaber #:

Der folgende Code enthält keine Fehler.

Sie verweisen gerne auf die Dokumentation. Das sagt alles über die Grenzen von ZeroMemory aus. Aber es wird nichts über die Einschränkungen von File* gesagt. Was ZeroMemory betrifft, so verlasse ich mich auf das, was ich habe. Das ist jetzt nicht praktisch, aber es scheint absichtlich so gemacht worden zu sein.

Wenn Sie diese beiden Funktionen vergleichen, arbeitet FileReadStruct nur mit einfachen Strukturen. Dies ist ein grundlegender Unterschied im Prinzip.

Es liegt ein Fehler vor (der Compiler informiert uns derzeit nur nicht darüber), und zwar folgender: Eine Funktion (nämlich FileReadStruct) außerhalb der Klasse erhält direkten Zugriff auf geschützte Mitglieder dieser Klasse, was dem Konzept von private, protected widerspricht.

Und inwiefern ist diese Funktion besser alsZeroMemory und Hunderte von anderen Funktionen? Nichts! - Die Entwickler haben sich einfach noch nicht damit beschäftigt.Auch ZeroMemory hatte zuvorkeine in der Dokumentation angegebenen Einschränkungen.Aber es ist jetzt da - und nicht, weil es Ihnen Unannehmlichkeiten bereitet - sondern weil ein einziges Prinzip funktioniert - obFileReadStruct oderZeroMemory oder Hunderte von anderen ähnlichen Funktionen - alle sind gleich.

 
A100 #:

dass hundert andere ähnliche Funktionen alle gleich sind

FileLoad/FileSave in die Ungleichheitsbox.

Die Bequemlichkeit wird nicht siegen!

Es gibt keinen Grund, sich in den Fuß zu schießen.

 
fxsaber #:

FileLoad/FileSave mehr zum Ungleichheitsfeld.

Es gibt keinen Grund, sich in den Fuß zu schießen.

Sie sind es, der sich selbst ins Bein schießt - indem Sie sich für privat erklären. Sie haben nur begrenzten Zugang zu sich selbst und werden sich dann wundern, warum der Code, bei dem der öffentliche Zugang für externe Funktionen erforderlich ist, plötzlich nicht mehr funktioniert

1...204205206207208209210211212213214215216217218...247
Neuer Kommentar
Grund der Beschwerde: