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

Nouveau commentaire
 
A100 #:

Et il n'est pas nécessaire de modifier le comportement des fonctions existantes - il suffit d'ajouter de nouvelles fonctions correctes (avec un préfixe/suffixe) et de déclarer les fonctions précédentes obsolètes avec un avertissement correspondant.

Détruire tout le sens de FileReadArray ? Considérez ces fonctions comme la sauvegarde d'un morceau de mémoire. Juste des octets.

 
fxsaber #:

Détruire l'intérêt de FileReadArray ? Considérez ces fonctions comme la sauvegarde d'un morceau de mémoire. Juste des octets.

Vous voulez donc d'abord vous créer des difficultés par le biais de l'accès privé et constant, puis les surmonter héroïquement par l'accès "direct" à la mémoire ?

J'ai une approche différente : si un tel besoin se fait sentir, cela signifie que le programme a été mal conçu dès le départ.

 
A100 #:

C'est-à-dire que vous proposez d'abord de vous créer des difficultés par le biais d'activités privées, constantes ou non.

J'ai toujours tiré un grand bénéfice de l'utilisation du privé/const. Ils vous permettent de contrôler très bien l'architecture du programme.

et les surmonter héroïquement par un accès "direct" à la mémoire ?

Aucun dépassement. Tout est très simple et logique.

Mon approche est différente : si un tel besoin se fait sentir, cela signifie que le programme a été mal conçu dès le départ.

Je comprends qu'ils sont prêts à tout écrire dans un tas (sans private/const), privant la commodité du contrôle architectural au nom de la "pureté" de la POO.

 
Ilyas #:

Le dossier... est apparu lorsque la confidentialité et la constance n'existaient pas, nous n'avons pas encore pensé à changer ce comportement, car nous ne le considérons pas comme critique.

CharArray<->Struct sont apparus récemment, mais ils fonctionnent bien avec private/const. Espérons qu'ils ne seront pas révisés.

 
Pour la propreté du code, les méthodes de sérialisation et de désérialisation doivent être écrites pour les structures. Il n'y aura donc pas de conflit de confidentialité et les champs constants ne sont pas constants s'ils peuvent être modifiés pendant la désérialisation.
 
fxsaber #:

Je comprends que vous êtes prêt à tout écrire dans un tas (sans private/const), privant la commodité du contrôle architectural au nom de la "pureté" de la POO.

Vous comprenez mal - du point de vue de la POO, l'objet est autosuffisant (il n'a pas besoin de fonctions externes) - il n'y a donc pas de conflit avec private. Et s'il y a un conflit avec la const, comme cela a été correctement noté :

C'est vous qui les avez rendues artificielles.
 
fxsaber #:

Je comprends que vous êtes prêt à tout écrire dans un tas (sans private/const), privant la commodité du contrôle architectural au nom de la POO "pure".

Vous êtes prêt à utiliser toutes les failles de l'accès direct à la mémoire par commodité au lieu d'utiliser une approche canonique moins pratique mais plus sûre.

 
TheXpert #:

C'est plutôt le contraire. Vous êtes prêt à utiliser toutes les failles de l'accès direct à la mémoire par commodité au lieu d'utiliser l'approche canonique moins pratique mais plus sûre.

Deux demandes :

  1. Montrez le code pour sauvegarder et charger la structure.
  2. Un exemple des dangers de l'approche non canonique.
 

Eh bien, c'est un bug féroce. Exemple :

class C{
   static uint count;
   const uint number;
public:
   C():number(++count){PrintFormat("C[%i]",number);}
  ~C(){PrintFormat("~C[%i]",number);}
   uint Number() const {return number;}
};
uint C::count=0;

void OnStart()
{
  C c[3]={};
  for(int i=0;i<ArraySize(c);Print(c[i++].Number()));
}
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        0
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]
2021.11.18 16:03:31.424 test (EURUSD,M1)        ~C[0]

La mémoire est allouée, le destructeur est appelé lorsqu'elle est libérée (ce qui laisse entrevoir le comportement attendu selon RAII), mais le constructeur est oublié pour être appelé lors de la création de l'objet))).

 

Je ne l'ai jamais vu auparavant.

1...206207208209210211212213214215216217218219220...247
Nouveau commentaire