Caractéristiques du langage mql5, subtilités et techniques - page 211

Nouveau commentaire
 
fxsaber #:

Vous avez vous-même signalé la 4ème erreur. Pourquoi ZeroMemory est-il pire que {} ? C'est-à-dire que nous avons un mécanisme non autorisé d'accès au privé qui n'est pas détecté par le compilateur pour une raison quelconque.

Vous pensez que les développeurs ne vont pas régler le problème ? A une époque, le compilateurne réagissait pas non plus àZeroMemory

 
A100 #:

Vous avez vous-même signalé la 4ème erreur. Pourquoi ZeroMemory est-il pire que {} ? C'est-à-dire que nous avons un mécanisme non autorisé d'accès au privé que le compilateur ne peut pas détecter pour une raison quelconque.

Je ne pense pas que ce soit une erreur. La structure n'a pas de constructeur mais elle est en cours d'initialisation. FileReadStruct - c'est une chose vraiment effrayante...

 
fxsaber #:

Je ne le vois pas comme une erreur. La structure n'a pas de constructeur, elle est initialisée. FileReadStruct est une chose assez effrayante alors.

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

À en juger par la description, il s'agit d' une sorte d'auto-illusion.

 
A100 #:

D'après la description, ça ressemble à une sorte d'auto-illusion.

Eh bien, oui - c'est de la tromperie.

 
A100 #:

A en juger par la description, c'est une sorte d'auto-destruction

Référence à la documentation sans tenir compte des artefacts copier-coller - étrange.

 
fxsaber #:

Des liens vers la documentation sans tenir compte des artefacts copier-coller - étrange.

Je vois cette fonction pour la première fois du tout - ils auraient pu m'informer qu'il y a une erreur dans la description

Il y a une erreur structurelle en plus de la description :

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
}

Pourquoi ZeroMemory est-il pire que FileReadStruct ?

Un autre espoir est que les développeurs ne le remarqueront pas, le reporteront ou seront trop paresseux pour le corriger (soulignez le point) ?

Mon argument est simple : à un moment donné, ZeroMemory a compilé avec tout cela (y compris le privé ), mais ils l'ont remarqué, ils s'en sont emparés et l'ont corrigé.

 
A100 #:

C'est la première fois que je vois cette fonction - ils auraient pu me dire qu'il y avait une erreur dans la description.

Je n'ai jamais regardé la description de cette fonction. Tout est clair dans le nom.

Outre la description, il y a également une erreur structurelle :

Il n'y a pas d'erreur dans le code suivant.

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

L'ennui ne l'emportera pas sur la commodité !


Pourquoi ZeroMemory est-il pire que FileReadStruct ?

Vous aimez vous référer à la documentation. Tout y est dit sur les limites de ZeroMemory. Mais il ne dit rien sur les limites de File*. En ce qui concerne ZeroMemory, je juge par ce que j'ai. Ce n'est pas pratique maintenant, mais cela semble avoir été fait exprès.

Mais si vous comparez ces deux fonctions, FileReadStruct ne fonctionne qu'avec des structures simples. Il s'agit d'une différence fondamentale.


Ce sujet porte sur les particularités de MQL5. J' en ai indiqué un (il ne fonctionne pas dans MQL4). Ce dialogue est, malheureusement, une perte de temps.

 
fxsaber #:

Il n'y a pas d'erreurs dans le code suivant.

Vous aimez vous référer à la documentation. Cela dit tout sur les limites de ZeroMemory à cet endroit. Mais il ne dit rien sur les limitations de File*. Quant à ZeroMemory, je me contente de ce que j'ai. Ce n'est pas pratique maintenant, mais cela semble avoir été fait exprès.

Mais si vous comparez ces deux fonctions, FileReadStruct ne fonctionne qu'avec des structures simples. Il s'agit d'une différence fondamentale de principe.

Il y a une erreur (le compilateur ne nous en informe pas pour le moment) et elle est la suivante : une fonction (à savoir, FileReadStruct) externe à la classe obtient un accès direct aux membres protégés de cette classe, ce qui contredit le concept même de private, protected.

Et en quoi cette fonction est-elle meilleure queZeroMemory et des centaines d'autres fonctions ? Rien ! - Les développeurs ne s'y sont pas encore mis.ZeroMemory ne spécifiait pas non plus de limitations dans la documentation auparavant.Mais il est là maintenant - et pas parce qu'il vous cause quelques inconvénients - mais parce qu'un seul principe fonctionne - que ce soitFileReadStruct ouZeroMemory, ou des centaines d'autres fonctions similaires - tous sont égaux.

 
A100 #:

que cent autres fonctions similaires sont toutes égales

FileLoad/FileSave dans la boîte d'inégalité.

La commodité ne l'emportera pas !

Il n'y a aucune raison de se tirer une balle dans le pied.

 
fxsaber #:

FileLoad/FileSave plus à la boîte d'inégalité.

Il n'y a aucune raison de se tirer une balle dans le pied.

C'est vous qui vous tirez une balle dans le pied - en vous déclarant privé. Vous avez un accès limité à vous-même et vous vous demanderez ensuite pourquoi le code où l'accès public est nécessaire pour les fonctions externes a soudainement cessé de fonctionner.

1...204205206207208209210211212213214215216217218...247
Nouveau commentaire