Mon approche. Le noyau est le moteur. - page 4

Nouveau commentaire
 
La POO n'interfère pas avec la mise en œuvre du noyau, au contraire.
En général, il y a du code et des données. Le noyau, dans notre cas, est le code, fortement séparé des données. Les données peuvent également être le code lui-même. Le noyau dispose généralement d'une fonctionnalité plus complète pour traiter des données spécifiques, ou du moins d'un minimum d'autosuffisance.
Cette approche vous permet d'utiliser le format de données le plus pratique, on suppose qu'il y aura beaucoup de données.
Voici un autre exemple où cette approche peut être appliquée : il y a beaucoup de stratégies dans l'Expert Advisor, les données ne représentent que la logique des stratégies, le noyau est la fonctionnalité pour les gérer, à savoir, la gestion des ordres, la gestion des risques, le travail avec l'environnement de trading, les indicateurs, la gestion des erreurs, l'affichage de certaines ou de toutes les statistiques, les fonctions de trailing/grid/......
 

Реter Konow:

Vous créez un tableau et y inscrivez les valeurs des propriétés du bouton que vous voulez créer.

Un bouton se compose de trois objets : Base, Texte, Image.

Chaque objet existe à l'intérieur d'un élément bouton, le tableau doit donc être bidimensionnel.

Alors, pourquoi s'embêter avec tous ces tableaux quand on peut (et doit) utiliser une structure pour cela. Et nous pouvons adresser ces valeurs de manière humaine - par le nom du champ, et non par l'index (ce qui peut causer beaucoup d'erreurs stupides).

Par conséquent, au lieu d'un tableau à deux dimensions, on aura un tableau de structures. La déclaration est aussi concise, mais la simplicité et la fiabilité sont beaucoup plus grandes, sans compter l'utilisation rationnelle de la mémoire, car chaque champ a son propre type. Et la POO n'a rien à voir avec tout cela.

Voici un exemple :

struct TObject { char type;  string name;  int x;  int y;  int width;  int height;  color clr; };

TObject Objects[]= { { OBJ_BITMAP, "Bitmap", 100, 100, 200, 200, clrRed },
                     { OBJ_BUTTON, "Button", 150, 150, 50, 10, clrWhite },
                   };
 
Alexey Navoykov:


Le résultat est un tableau de structures au lieu d'un tableau à deux dimensions. La déclaration est la même, mais la commodité et la fiabilité sont bien plus grandes, sans compter l'utilisation rationnelle de la mémoire, car chaque champ a son propre type. Et la POO n'a rien à voir avec tout cela.


C'est un peu ambigu... qu'est-ce qui est le mieux - un tableau de structures ou une structure de tableaux ?

mais MQL est conçu pour fonctionner avec des tableaux Forthran, c'est un fait...

 
Maxim Kuznetsov:

Il y a un petit dilemme ici... qu'est-ce qui est mieux - un tableau de structures ou un tableau de structures ?

De quel type de structure de tableau parlons-nous ? L'auteur a juste des tableaux

 

Je ne pense pas que Peter ait déjà vu comment créer un modèle de DialogBox en Visual C++, y glisser et déposer n'importe quel contrôle, comme un bouton, une case à cocher, une case d'édition, une case à compléter, etc.

En d'autres termes, les éléments que vous pouvez voir dans Windows, y compris différentes options d'affichage des chaînes de DB avec des ajustements de champs et de chaînes.

Et avec l'utilisation de MFC, vous pouvez créer des boîtes de dialogue assez complexes en quelques minutes et très brièvement.

 
Alexey Navoykov:

Et pourquoi toutes ces perversions avec un tableau, alors que vous pouvez (et devriez) utiliser une structure à cette fin. Il est initialisé exactement de la même manière - avec des valeurs, séparées par des virgules. Et ces valeurs sont accessibles humainement - par le nom du champ, et non par l'index (ce qui peut conduire à de nombreuses erreurs stupides).

Par conséquent, au lieu d'un tableau à deux dimensions, on aura un tableau de structures. La déclaration est aussi concise, mais la simplicité et la fiabilité sont beaucoup plus grandes, sans compter l'utilisation rationnelle de la mémoire, car chaque champ a son propre type. Et la POO n'a rien à voir avec tout cela.

Voici un exemple :

C'est une bonne solution. Mais cette structure ne peut pas être intégrée dans le noyau. Si lors de la construction d'un noyau selon ma technologie, il suffit de faire une boucle sur le tableau avec les éléments du prototype et de les réécrire dans le noyau, dans le cas de votre solution, la boucle est impossible.

Cela pourrait être possible, mais chaque élément devrait être intégré dans une structure distincte. Et comment l'afficher sur la portée globale ? Où déclarer tout cela... Ce n'est pas clair.

Le mien est simple. Un tableau de prototypes d'éléments. Toutes les propriétés des objets s'y trouvent. Le tableau lui-même est global. L'accès est le plus simple et se fait de n'importe où dans le programme.

 
Vos tripes ne résistent-elles pas à l'utilisation de doubles ? Après tout, c'est aussi un objet composite avec ses propres méthodes. Il n'y a pas de place pour eux dans les réseaux de noyaux orthodoxes ! Regardez, parce que c'est impressionnant (mantisse, exposant, signe) :
_NEW_OBJECT, тра-та-та-та-та-та, 3, 10, 1, тра-та-та-та-та-та
 
pavlick_:
Vos tripes ne résistent-elles pas à l'utilisation de doubles ? Après tout, c'est aussi un objet composite avec ses propres méthodes. Il n'y a pas de place pour eux dans les réseaux de noyaux orthodoxes ! Regardez, c'est impressionnant (mantisse, exposant, signe) :

Je ne comprends pas.

 

Je me débarrasse de la syntaxe inutile et du tambourin, j'initialise simplement les propriétés des éléments dans un tableau prototype global.

Il n'est utilisé qu'une seule fois - lorsque les prototypes d'éléments sont réécrits en Kernel.

La réécriture se fait dans une simple boucle.

Par conséquent, au stade de la construction, le noyau commence à contenir des prototypes d'éléments sélectionnés par l'utilisateur.

Ensuite, de nouveaux cycles sur le noyau commencent. J'y écris les valeurs définies par l'utilisateur pour les propriétés des éléments.

À la fin, vous obtenez un Kernel fini, qui contient les fenêtres utilisateur finies avec tous les éléments.

 

Le processus décrit ci-dessus, je l'appelle le "processus de construction du noyau".

Une fois le noyau construit, le "moteur" commence à fonctionner.

Le moteur est le code qui contrôle la mécanique des éléments.

Le moteur n'est formé que pour travailler avec le noyau. Son moteur est constitué de divers événements (provenant principalement de OnChartEvent()).

1234567891011...184
Nouveau commentaire