La POO sera-t-elle demandée dans MQL5 ? - page 6

Nouveau commentaire
 

Si vous voulez, vous pouvez trouver la POO en BASIC, qui est aussi un interprète.


Je pense que nous devons attendre et voir à quel point la POO sera demandée dans les indicateurs, les Expert Advisors et les scripts. Et sur le fait de décider ce qu'il en est réellement.

 

HideYourRichess писал(а) >>

Je pense que nous devrions attendre et voir à quel point la POO sera demandée dans les indicateurs, les EA et les scripts. Et ensuite décider comment cela fonctionne réellement.

En ce moment, j'essaie d'automatiser la copie des tampons de données avec tous les indicateurs. C'est un processus difficile, je suis toujours confronté à des problèmes tels que l'absence de références, les constructeurs avec des paramètres (RAII est irréalisable), etc.

Et je ne suis pas satisfait d'une chose similaire qui vient avec. Pas du tout.

C-4 a écrit >>

Z.U. La plupart des gens associent la POO à un langage de programmation particulier : C++.

Pourquoi, il est mal mis en œuvre ? Imho, assez bien mis en œuvre. Comme dans tout autre langage orienté objet normal.

MQ5 est une OOP,

Mais il est pauvre en fonctionnalités.

La POO existe même en C, et pourtant, pour une raison quelconque, beaucoup ne la connaissent pas, ce qui témoigne encore une fois d'une connaissance superficielle.

Veuillez expliquer un peu plus ce point.

 
TheXpert >> :

Maintenant j'essaie d'automatiser la copie des données de la mémoire tampon avec tous les accompagnements dans les indicateurs. C'est difficile, c'est compliqué, je me heurte constamment à des murs comme le manque de références, les constructeurs avec paramètres (RAII est irréalisable), etc.

Et je ne suis pas satisfait d'une chose similaire qui vient avec. Pas du tout.

Pour te dire la vérité, j'ai essayé ça aussi. Ce n'était rien de spécial, juste un coup d'essai. J'ai laissé tomber, je n'en ai rien tiré de bon. Soit j'ai besoin de me recycler beaucoup, soit l'OOP doit être étendu. Ni l'un ni l'autre ne sont encore attendus. En général, j'ai dépassé le râteau, et je n'ai pas compris si j'étais un tel imbécile ou si je devais envoyer des tickets au support technique, - j'ai abandonné tout cela pour le moment.

 

S'il vous plaît, je peux développer :

INCAPSULATION :

struct mail

{

int zipcode;

char adr[50];

char comment[10];

...

}

La simple présence de structures est une encapsulation non protégée.

POLYMORPHISME STATIQUE :

double d=3.12, c;

int i=5;

c=d+i;

(Des types de données différents sont additionnés par le même opérateur)

LE POLYMORPHISME DYNAMIQUE :

void qsort(void *buf, size_t st, size_t s,int (*compare) (const void *, const void *));

La fonction qsort se comportera différemment, selon le type de sous-fonction de comparaison

.

INCLAPSULATION :

Même exemple que dans le polymorphisme dynamique, dans ce cas la fonction qsort prend en quelque sorte les propriétés de compare()

 
C-4 >> :

S'il vous plaît, je peux développer :

C'est quelque chose comme ça que je m'attendais à voir. Seul le polymorphisme statique est comptabilisé. Je ne vois pas l'intérêt de poursuivre la discussion sur ce sujet (la POO en C) et je ne le ferai pas.

Je pensais que tu me surprendrais vraiment.

 
Si vous voulez voir quelque chose comme la surcharge classique des fonctions, etc., téléchargez un compilateur C moderne, par exemple LCC, et consultez-le. Le LCC, par exemple, prend en charge la POO classique, bien que cela soit en dehors de la norme.
 

Pour résumer certains résultats très préliminaires, nous pouvons dire que la POO dans l'implémentation des méta-citations n'est pas acceptée même par les programmeurs expérimentés. C'est peut-être à cause de la mise en œuvre. Peut-être faudra-t-il s'y habituer et la POO deviendra vraiment plus pratique. Mais jusqu'à présent, nous avons ce que nous avons. Il semble que ce soit plus pratique sans elle. C'est-à-dire que vous pouvez probablement l'écrire, mais seulement pour la POO, pas pour la facilité d'utilisation, la vitesse d'écriture, sans parler des performances du code lui-même, qui de toute façon sera plus lent contre PP.

C'est le cas...

 

Le besoin de POO est-il vraiment si important (peu importe qui comprend sous cette abréviation) ? Pour moi, il est plus important de savoir quelles nouvelles fonctions de négociation et de service apparaîtront et faciliteront le travail du négociant et du programmeur, et comment elles seront bien/complètement mises en œuvre.

Si vous me montrez au moins dix certificats de conformité de MQL5 aux normes de la POO, mais sans la création d' objets par des indicateurs, aucune POO ne vous sauvera des subtilités de l'affichage d'un simple texte à l'écran. A quoi bon une utilisation fière de la POO, si vous ne pouvez même pas utiliser une molette commune dans cet objet graphique ? Un bouton qui fonctionne comme une case à cocher, et l'absence d'une boîte combo standard, de sorte que, par exemple dans un conseiller expert, vous pourriez simplement sélectionner la période pour les calculs, et la possibilité de regrouper plusieurs objets en un seul. Je ne parle même pas de l'éditeur de formulaires de dialogue, parce que la plate-forme est développée pour l'auto-trading ... :(

IMHO : Dans MQL5, il n'existe qu'une version (fortement) tronquée des possibilités inhérentes à la POO classique. Les développeurs ont fait un excellent travail et cela simplifie sûrement l'écriture d'un code source, mais tout cela est vain, et je veux toujours un taxi, et j'espère que les développeurs ne commenceront pas à travailler sur MQL6 bientôt, mais qu'ils travailleront fructueusement longtemps pour "finaliser" MQL5 ;)

 
ForexTools >> :

Mais la demande de POO est-elle si importante (peu importe qui comprend cet acronyme) ? Pour moi, il est beaucoup plus important de savoir quelles nouvelles fonctions de négociation et de service apparaîtront pour faciliter le travail du négociant et du programmeur, et dans quelle mesure elles seront bien/complètement mises en œuvre.

Oui, bien sûr. Et beaucoup de choses ont été dites à ce sujet dans les fils de discussion correspondants. Il me semble, par exemple, que MC, au lieu de résoudre de vieux problèmes, n'a fait que rendre leur solution plus compliquée par des innovations.

Je ne parle pas d'OOP pour l'instant. Mais l'énergie dépensée pour cette fonctionnalité aurait très bien pu être consacrée à quelque chose de réellement utile et en demande.

 
Svinozavr >> :

Oui, bien sûr. Et beaucoup de choses ont été dites à ce sujet dans les fils de discussion pertinents. Il me semble, par exemple, que le MC, au lieu de régler les anciens problèmes, n'a fait que compliquer leur solution par des innovations.

Je ne parle pas de l'OLP maintenant. Mais l'énergie dépensée pour cette opportunité, il serait tout à fait possible de la dépenser pour quelque chose de vraiment utile et en demande.

Ce n'est pas une question simple, vraiment. En fait. Nous ne voyons pas de refonte du serveur. Selon des informations sommaires sur Internet, il est plus frais qu'avant. Tout cela n'est certainement pas pour nous, pour les DT, mais d'un autre côté le service peut s'améliorer, en général.

123456789
Nouveau commentaire