Aide sur la POO - page 3

 
Vasiliy Sokolov #:

OK. Je ne comprends pas. Vous comprenez ? Vous êtes sûr de comprendre ? Exactement ?

L'argument se résume à l'affirmation suivante :

...

Il ne s'agissait pas d'un argument général, mais d'une situation concernant un seul message, et j'ai expliqué quel était le problème. Ok, il n'y a pas eu de catastrophe.

 

Tableau déclaré double x [268435448];

Le même tableau dans la fonction OnStart().

J'ai aussi fait un appel récursif avec une profondeur LONG_MAX.

Aucun problème.

 
fxsaber #:

Vous n'utilisez pas de tableaux statiques ?

grande. Si la taille du tableau est petite, constante et connue à l'avance, la statique est meilleure et probablement plus rapide.

 
Andrei Trukhanovich #:

grande. Si la taille du tableau est petite, constante et connue à l'avance, la statique est meilleure et probablement plus rapide.

J'aimerais avoir un moyen d'obtenir une liste des variables/rays statiques et de leurs tailles. Vous aurez probablement besoin d'un analyseur de code comme ici.

Je suppose que les tableaux de chaînes statiques et les tableaux de doubles sont des choses bien différentes.

MQL5 Program Packer
MQL5 Program Packer
  • www.mql5.com
This is MQL5 project packer: assemble all source and resource files from dependencies into a single ZIP.
 
fxsaber #:

Je suppose que les tableaux statiques de chaînes et les tableaux doubles sont des choses bien différentes.

la chaîne de caractères est essentiellement une classe interne constituée d'un pointeur et d'une taille int, c'est-à-dire que pour un tableau double, elle occupera conditionnellement 1,5 fois moins d'espace

Je ne pense pas qu'il y ait beaucoup de sens à s'en préoccuper, sauf si vous avez des tableaux statiques avec des millions d'éléments.

 
fxsaber #:

Ne pas utiliser de tableaux statiques ?

Il existe donc essentiellement quatre types de données dans MQL :

  • Données statiques et prédéfinies. Intégré au programme au moment de la compilation et n'est plus modifié. Ils sont situés dans un espace mémoire privé. Par exemple, il s'agit de tableaux statiques de type char[1024].
  • Données gérées manuellement par les pointeurs. Ce sont des instances de classes mais définies par un pointeur, par exemple CFoo* bar où bar est une instance de CFoo. Ces instances sont de type POINTER_DYNAMIC. Ce type de stockage est le plus problématique, bien qu'il ne soit pas nécessaire dans la plupart des cas.
  • Données gérées par le collecteur de déchets de la machine virtuelle mql dans laquelle le programme est exécuté. Cela inclut les instances des classes. Le pointeur vers un objet de ce type sera POINTER_AUTOMATIC. Ces objets se trouvent eux-mêmes soit dans le tas de cette machine virtuelle, soit dans une section privée. La manière exacte de procéder dépend des données et de leur taille, apparemment, et de ce dont disposent les développeurs. Cette information n'est pas disponible. Ces données comprennent, par exemple, les classes d'utilisateurs. Toute définition d'une instance de classe sans pointeur définit ce type de stockage. Par exemple, CFoo bar définit une instance de la classe CFoo bar, dont le pointeur n'a pas besoin d'être libéré. La machine virtuelle effectue toutes les opérations de déblocage. Vous n'avez pas besoin d'utiliser l'opérateur de suppression et donc de faire face au problème des objets perdus.
  • Données situées sur la pile. Ce sont, tout d'abord, des variables locales de fonctions. Par exemple, lorsque nous écrivons int a = 5 dans une fonction, le sommet de la pile est déplacé de 4 octets vers le haut, allouant ainsi la taille de mémoire nécessaire. Peut-être que, dans MQL, les types stockés sur la pile incluent également les structures (je n'ai jamais vérifié, pour être honnête). Ces données ne prennent pas beaucoup de place, et même en tenant compte d'une chaîne d'appels de fonctions imbriquées, la pile dans son ensemble nécessite beaucoup moins de mémoire qu'un tas. Ce type de stockage est utilisé automatiquement, vous n'avez pas besoin d'y penser.

Si nous laissons la pile aux fonctions et à leurs variables locales, il nous reste trois types avec lesquels travailler. Je crois personnellement (et ce n'est que mon opinion) que les données définies avec une durée de vie automatique combinent bien les avantages des deux types précédents, sans leurs inconvénients. Les données définies à l'aide d'un pointeur automatique sont aussi prévisibles et sûres que les données statiques, mais tout aussi flexibles que les données dynamiques, contrôlées manuellement. Par prévisibilité, j'entends les scénarios dans lesquels il n'est pas nécessaire de procéder à des vérifications supplémentaires des bits de pointeur et de se demander si quelqu'un d'autre a déjà supprimé les données auparavant. Par flexibilité, j'entends des scénarios dans lesquels on peut travailler avec des données référencées par un auto-pointeur comme avec un pointeur normal, en passant le pointeur à une fonction ou, pour les tableaux, en le recyclant.

Pour illustrer ce que je viens de dire, vous pouvez comparer le code initial fourni par Ihor Herasko et le même code que j'ai écrit pour POINTER_AUTOMATIC. Il n'y a pas de contrôles et d'initialisations supplémentaires, pas de suppression d'opérateur 60 000 000 de fois. Tout cela vous permet d'économiser du temps, des efforts et, ce qui est également important, des ressources. Si vous le comprenez, vous n'aurez presque jamais besoin de travailler avec des pointeurs. Vous pouvez toujours écrire un tel algorithme qui minimiserait ce travail ou ne le ferait pas du tout. Par exemple, je ne manipule jamais les objets manuellement dans mon code - ce n'est tout simplement pas nécessaire. Quant aux tableaux statiques, je dois parfois les utiliser, par exemple, pour coudre dans le programme les données dont il a besoin, mais il s'agit de choses si spéciales, que les utilisateurs ordinaires, je suppose, n'en ont pas besoin. Il est préférable d'utiliser des collections prêtes à l'emploi telles que CArrayObj, ou vos propres collections. Aujourd'hui, les modèles et les capacités MQL vous permettent de créer des choses assez flexibles qui sont bien meilleures que les tableaux statiques.

 
Il n'y a pas de collecteur d'ordures dans l'emcool.
 

Vasiliy Sokolov #:

Données statiques et prédéfinies. Intégrée dans le programme au moment de la compilation, elle n'est plus modifiée. Ils sont stockés dans une zone de mémoire privée. Par exemple, ce sont des tableaux statiques du type char[1024].

Si le tableau n'est pas initialisé,

int A[] = {1, 2}; // Инициализация
int B[2];         // Без инициализации

pourquoi devrait-elle être inscrite dans EX5 ?

 
fxsaber #:

Si le tableau n'est pas initialisé,

pourquoi devrait-il être intégré dans EX5 ?

Oui, c'est vrai, ceux qui ne sont pas initialisés ne sont pas cousus, bien sûr. Ceux qui sont initialisés le sont. Mais les tailles des deux types sont définies au moment de la compilation et ne changent plus. En d'autres termes, les tableaux statiques peuvent être divisés conditionnellement en deux groupes.

 
Dmitry Fedoseev #:
Il n'y a pas de collecteur d'ordures dans emcool.

Officiellement, oui. Officieusement, beaucoup de choses indiquent qu'elle existe :

  • Il n'y a pas de pointeurs dans MQL. Au lieu de cela, ils sont remplacés par quelque chose qui leur ressemble beaucoup.
  • Il n'y a pas d'allocation directe de mémoire dans MQL, comme en C par exemple ;
  • Les programmes en MQL sont exécutés par une certaine machine virtuelle. Renat en a parlé brièvement et pas une seule fois ;
  • L'instance de la classe peut être définie, puis elle sera automatiquement libérée. Il existe donc un mécanisme qui surveille ces instances et les libère si nécessaire. Qu'est-ce que c'est si ce n'est un collecteur d'ordures ?
  • Toute instance initialisée par le biais d'un pointeur et qui n'est pas correctement libérée sera marquée comme objet fui à la sortie. Leur nombre et la taille totale de la mémoire perdue seront imprimés. Un programme avec une fuite de mémoire ne sera même pas validé dans Market. Ainsi, tous les objets, même ceux attribués manuellement, sont comptabilisés, connus et connus du système. C'est l'une des tâches classiques que le collecteur d'ordures résout.