Sujet intéressant pour beaucoup : les nouveautés de MetaTrader 4 et MQL4 - de grands changements en perspective - page 10

[Renat Fatkhullin]

N'oubliez pas que nous avons un très bon inliner en fonctionnement, qui draine beaucoup de petites fonctions, de sorte qu'il n'y a pas de perte de vitesse.

Et dans la plupart des cas, les appels aux fonctions virtuelles via vtable sont optimisés en appels directs. C'est l'une des méthodes efficaces de l'optimiseur. Ce qui, couplé à l'inlining multiple, vous permet de vous débarrasser presque complètement des appels complexes à plusieurs niveaux et de rendre le code plat.

[Mykola Demko]

Renat:

N'oubliez pas que nous avons un très bon inliner en fonctionnement, qui draine beaucoup de petites fonctions, de sorte qu'il n'y a pas de perte de vitesse.

Et dans la plupart des cas, les appels aux fonctions virtuelles via vtable sont optimisés en appels directs. C'est l'une des méthodes efficaces de l'optimiseur. Ceci, couplé à l'inlining multiple, vous permet de vous débarrasser presque complètement des appels complexes à plusieurs niveaux et de rendre le code plat.

:) drôle. Et personne ne conteste que le compilateur optimise parfaitement le code, je montre juste à mon ami pourquoi je ne me couche pas devant SB.

Ok, prenons des exemples :

class CiCustom : public CIndicator : public CDoubleBuffer

                пользуется включением class CSeries : public CArrayObj который в свою очередь

                                                     пользуется включением class CArrayDouble : public CArray и

                                                                           class CArrayObj : public CArray ну и конечно куда как без

                                                                                  включения class CArray : public CObject который включает

                                                                                                           class CObject и #include "StdLibErr.mqh"

est remplacé en pratique par une simple fonction standard

CopyBuffer(...);

Nous avons l'art pour l'art. Et ainsi de suite pour chaque élément qui fait quelque chose (le reste, comme vous le comprenez, est écrit pour que les derniers éléments fonctionnent).

Oui, je suis d'accord sur la polyvalence, oui, je suis d'accord sur le code bien structuré (vous pouvez dire, c'est un échantillon pour l'analyse).

Mais quelle est l'essence de tout cela ? Le fait est que cette bibliothèque est principalement nécessaire pour l'assistant MQL5 et en tant que tutoriel sur la POO.

[Georgiy Merts]

Urain:

Je fais simplement comprendre au camarade pourquoi je ne m'écroule pas devant le SB.

Oui, oui, je le souligne à nouveau - je n'ai aucune objection sérieuse à aucun de vos arguments. Un argument sur ce point serait plus religieux qu'objectif.

Eh bien, juste sur votre exemple, personnellement MOI, et DANS MON CAS, il semble plus acceptable exactement la première variante du code, en raison de toutes ces inclusions à plusieurs niveaux qui assurent la compatibilité de l'indicateur avec toutes les interfaces, à partir de CObject et jusqu'à CiCustom.

Mais d'un autre côté, toutes les séries chronologiques et tous les indicateurs sont créés à la demande, empilés dans une seule collection et ensuite disponibles pour tous les utilisateurs. Et lorsque nous n'avons besoin de copier un tampon qu'une seule fois, nous nous demandons pourquoi nous nous donnons tant de mal.

Ainsi, dans un cas simple, il serait bien sûr beaucoup plus facile d'utiliser CopyBuffer().

Mais que se passe-t-il si nous avons une douzaine d'utilisateurs pour un tampon donné ? Dans mon cas, ils le demanderont tous, le tampon sera créé et tous les autres obtiendront une référence à celui-ci. Et si nous utilisons CopyBuffer() "directement" - j'aurai dix copies au lieu d'une. Et lorsque vous utilisez CopyBuffer() de manière plus astucieuse, vous obtenez des fonctionnalités permettant de suivre qui et quel tampon a été alloué, ce qui est tout à fait équivalent à l'encapsulation que vous avez mentionnée.

Personnellement, je suis pour la raisonnabilité - cela n'a pas de sens de faire un si grand complot avec OOP pour un seul endroit. Si nous avons beaucoup d'utilisateurs, alors l'approche OOP, à mon avis, se justifie.

[[Supprimé]]

Urain:

Il est alors temps d'introduire des exceptions afin qu'un seul code puisse être compilé pour mql4 et mql5.

La question de l'unification se pose.

D'accord. Fonction très pratique.

C-4:
Je pensais que lors de la fusion de deux langages, les directives de compilation conditionnelle comme #ifdef sont absolument nécessaires - cela simplifierait l'unification des codes entre les deux plateformes, et les API dépendantes de la plateforme seraient définies au moment de la compilation.

Nous sommes au moins quatre maintenant :)

[[Supprimé]]

Renat:
Malheureusement, non. Le testeur restera mono-fil et sans MQL5 Cloud Network.

Qu'en est-il de la multidevise ?

[Renat Fatkhullin]

Dans Mt4, l'idéologie du testeur restera la même. Nous ne procéderons à aucun changement fondamental, du moins pas dans un avenir proche.

[Georgiy Merts]

Renat:

N'oubliez pas que nous avons un très bon inliner en fonctionnement, qui draine beaucoup de petites fonctions, de sorte qu'il n'y a pas de perte de vitesse.

Et dans la plupart des cas, les appels aux fonctions virtuelles via vtable sont optimisés en appels directs. C'est l'une des méthodes efficaces de l'optimiseur. Ce qui, couplé à l'inlining multiple, vous permet de vous débarrasser presque complètement des appels complexes à plusieurs niveaux et de rendre le code plat.

Ahhhh... Je comprends maintenant pourquoi l'une de mes erreurs les plus fréquentes lorsque j'écris un programme est "La fonction doit avoir un corps".

C'est l'inliner qui nécessite... Je me demandais pourquoi je pensais qu'un en-tête de fonction était suffisant pour compiler un module, mais non... Vous avez besoin d'un corps...

C'est bien.

[Renat Fatkhullin]

Laryx:

Ahhhh... Je comprends maintenant pourquoi l'une de mes erreurs les plus fréquentes lorsque j'écris un programme est "La fonction doit avoir un corps".

C'est l'inliner qui nécessite... Je me demandais pourquoi je pensais qu'un en-tête de fonction était suffisant pour compiler un module, mais non... Vous avez besoin d'un corps...

C'est exact, mais cela n'a rien à voir avec l'optimiseur.

Si vous avez décrit le prototype d'une fonction de classe, le corps doit s'y trouver. Même si elle est vide.

[[Supprimé]]

Renat, je suggère que dans MT4 nous fassions la visibilité des positions sur le contrôle du graphique non pas dans les paramètres généraux du terminal, mais séparément pour chaque graphique (comme cela a été fait dans MT5).

Ma demande au SR à ce sujet est en suspens depuis deux mois maintenant.

[Renat Fatkhullin]

Interesting:

Renat, je suggère que dans MT4 nous fassions la visibilité des positions sur le contrôle du graphique non pas dans les paramètres généraux du terminal, mais séparément pour chaque graphique (comme cela a été fait dans MT5).

Ma demande au SR à ce sujet est en suspens depuis deux mois maintenant.

En travaillant sur les objets, nous verrons.