Version bêta de l'IDE MetaTrader 4 comprenant un nouveau compilateur et un nouvel éditeur MQL4 - page 5

 
Il est probablement difficile de trouver une suggestion d'optimisation plus mesquine, mais il est peut-être temps d'organiser la sortie de la liste Market Overview par ordre alphabétique après tout ? Ou est-ce l'ingénieur en moi qui dit que tout devrait être parallèle/perpendiculaire... Pas stressant, mais pas heureux non plus. Vous pourriez peut-être ajouter quelques lignes supplémentaires à ces 90% de fonctions prêtes à l'emploi, hein ?
 
Zaxvatov:
Il est probablement difficile de trouver une suggestion d'optimisation plus mesquine, mais il est peut-être temps d'organiser la sortie de la liste Market Overview par ordre alphabétique après tout ? Ou est-ce l'ingénieur en moi qui dit que tout devrait être parallèle/perpendiculaire... Pas stressant, mais pas heureux non plus. Vous pourriez peut-être ajouter quelques lignes supplémentaires à ces 90% de fonctions prêtes à l'emploi, hein ?
Il y a une application pour ça. Mais un bouton serait mieux...
 
VOLDEMAR:

Question : A quand le nouveau mt ? ??? Je ne peux pas attendre .....

Qu'attendez-vous exactement ? De nouveaux bugs ? (ce qui est inévitable avec des changements aussi importants). Cela vous démange de réécrire et de déboguer tous vos codes qui ne fonctionneront pas dans un instant ? Vous n'avez pas de temps libre à perdre ?

Personnellement, tout ce désordre avec les constructions récentes m'a fait réfléchir globalement aux perspectives d'une telle programmation MQL. Et ça n'a pas d'importance si c'est sur 4 ou 5. L'essence est la même. Vous écrivez vos programmes dans un certain langage synthétique qui est lié à une plate-forme de négociation, et finalement vous devenez l'otage de tous les caprices et erreurs des développeurs de la plate-forme/du langage. Aujourd'hui, ils veulent croiser MQL4 avec MQL5, demain avec MQL6, etc. Et vous n'avez pas le choix, vous êtes obligé de revoir vos développements en fonction de nouvelles règles. Sinon, tout cessera de fonctionner. Et ainsi de suite. Ce n'est pas grave.

D'une manière générale, cela a été pour moi le coup de pouce final pour transférer tous mes programmes MQL dans un environnement de programmation indépendant, sans lien avec une plate-forme de négociation spécifique. Et j'utiliserai MQL juste comme un lien de connexion entre MT et mon programme. Et c'est probablement la seule bonne manière. Sauf si vous avez l'intention de vendre vos aménagements sur le marché, bien sûr).

Eh bien, si vous aimez juste programmer en MQL et que vous voulez quelques nouvelles fonctionnalités (c'est-à-dire un intérêt sportif), alors qu'est-ce qui vous empêche de coder en P5, où tout cela est déjà implémenté ?

 
Meat:

Qu'attendez-vous exactement ? Plus de bugs ? (ce qui est inévitable avec des changements aussi importants). Cela vous démange de réécrire et de déboguer tous vos codes qui ne fonctionnent pas en un clin d'œil ? Vous n'avez pas de temps libre à perdre ?

Personnellement, tout ce désordre avec les constructions récentes m'a fait réfléchir globalement aux perspectives d'une telle programmation MQL. Et ça n'a pas d'importance si c'est sur 4 ou 5. L'essence est la même. Vous écrivez vos programmes dans un certain langage synthétique qui est lié à une plateforme de trading, et finalement vous devenez l'otage de tous les caprices et erreurs de cette plateforme / des développeurs du langage. Aujourd'hui, ils veulent croiser MQL4 avec MQL5, demain avec MQL6, etc. Et vous n'avez pas le choix, vous êtes obligé de revoir vos développements en fonction de nouvelles règles. Sinon, tout cessera de fonctionner. Et ainsi de suite. Ce n'est pas grave.

D'une manière générale, cela a été pour moi le coup de pouce final pour transférer tous mes programmes MQL dans un environnement de programmation indépendant, sans lien avec une plate-forme de négociation spécifique. Et j'utiliserai MQL juste comme un lien de connexion entre MT et mon programme. Et c'est probablement la seule bonne manière. Sauf si vous avez l'intention de vendre vos aménagements sur le marché, bien sûr).

Eh bien, si vous aimez juste programmer en MQL et que vous voulez quelques nouvelles fonctionnalités (c'est-à-dire un intérêt sportif), alors qu'est-ce qui vous empêche de coder en P5, où tout cela est déjà implémenté ?

Je suis d'accord, si le développeur laissait le support pour travailler sur les anciennes versions, au moins 500 et supprimer la mise à niveau obligatoire vers une nouvelle version, ce que je soupçonne d'être mis en œuvre, il serait ok, mais c'est un autre mouvement incompréhensible développeurs. Bien sûr, je suis favorable à l'inclusion de la POO, mais elle est facilement mise en œuvre dans un DLL et il n'est pas nécessaire d'allumer un feu avec une nouvelle version du langage comme nouvelle norme. Par exemple, le même C++, ils ont plusieurs normes existantes, mais en général il y a une base commune qui fonctionnera pour n'importe quelle implémentation de code.
 
Barbarian:
Je suis d'accord, si le développeur laissait le support pour les anciennes versions, au moins 500 et supprimait la mise à niveau obligatoire vers une nouvelle version, ce qui, je le soupçonne, sera mis en œuvre, ce serait ok, mais c'est un autre mouvement incompréhensible des développeurs. Bien sûr, je suis favorable à l'inclusion de la POO, mais elle est facilement mise en œuvre dans un DLL et il n'est pas nécessaire d'allumer un feu avec une nouvelle version du langage comme nouvelle norme. Par exemple, le même C++, ils ont plusieurs normes existantes, mais en général il y a un terrain commun qui fonctionnera pour n'importe quelle implémentation de code.

J'ai le sentiment que vous utilisez des fers à repasser en fonte et que vous chauffez la cuisinière au charbon... Les innovations sont bonnes, non seulement le marché des devises est très dynamique et vous devez toujours être dans la tendance si vous voulez réaliser quelque chose ... de nouveaux changements pour le mieux, espérons-le ....
 
VOLDEMAR:

Les innovations sont bonnes, non seulement le marché des devises est très dynamique et vous devez toujours être dans la tendance si vous voulez réaliser quelque chose ... de nouveaux changements pour le mieux, espérons-le ....

C'est une chose d'être soi-même "à la mode", mais c'en est une autre de voir ses anciens modèles devenir "à la mode". Si vous n'en avez pas beaucoup ou s'ils n'ont aucune valeur, pas de problème. Mais beaucoup de gens ici ont accumulé une énorme base de code, écrite et déboguée pendant des années. Et maintenant, tout le monde est mis devant le fait qu'une partie considérable de ce code va bientôt cesser de fonctionner. C'est absurde. Dans ce cas, la rétrocompatibilité, c'est-à-dire la prise en charge des anciennes versions du langage, est toujours envisagée, mais les métacitations ne le font pas.

 
Meat:

C'est une chose d'être soi-même "à la mode", mais c'en est une autre de voir ses anciens modèles devenir "à la mode". Si vous n'en avez pas beaucoup ou s'ils n'ont aucune valeur, pas de problème. Mais beaucoup de gens ici ont accumulé une énorme base de code, écrite et déboguée pendant des années. Et maintenant, tout le monde est mis devant le fait qu'une partie considérable de ce code va bientôt cesser de fonctionner. C'est absurde. Dans des cas comme celui-ci, la rétrocompatibilité est toujours envisagée, c'est-à-dire la prise en charge des anciennes versions de la langue, mais les métacitations ne le font pas.


En êtes-vous sûr ? Est-ce un initié ?
 
Meat:

C'est une chose d'être soi-même "à la mode", mais c'en est une autre de voir ses anciens modèles devenir "à la mode". Si vous n'en avez pas beaucoup ou s'ils n'ont aucune valeur, pas de problème. Mais beaucoup de gens ici ont accumulé une énorme base de code, écrite et déboguée pendant des années. Et maintenant, tout le monde est mis devant le fait qu'une partie considérable de ce code va bientôt cesser de fonctionner. C'est absurde. Dans des cas comme celui-ci, la rétrocompatibilité est toujours envisagée, c'est-à-dire la prise en charge des anciennes versions de la langue, mais les métacitations ne le font pas.

Paroles d'un alarmiste. Metacquotes a dit à plusieurs reprises, et ne se lassera probablement pas de le répéter, qu'il y aura une compatibilité totale. Arrêtez avec ces enfantillages.
 
FAQ:

Vous en êtes sûr ? Est-ce un initié ?

artmedia70:
Les mots d'un alarmiste. Les méta-citations ont dit à plusieurs reprises et ne se lasseront probablement pas de répéter qu'il y aura une compatibilité totale. Tu vas arrêter avec tes enfantillages ?

Je l'ai mis en évidence ici, afin que personne ne puisse dire qu'il est entièrement compatible :

Renat:


Quelles sont les différences par rapport à l'ancienne version de MQL4 :

  • La priorité des opérations booléennes ET/OU a changé. Maintenant tout est comme en C/C++ classique

  • Une évaluation raccourcie des expressions logiques a été introduite. Désormais, lors de l'évaluation d'une expression logique, les sous-expressions restantes ne sont pas évaluées. Comme en C/C++.

  • L'opérateur switch n'utilise désormais que des valeurs entières. Auparavant, on pouvait utiliser de vraies pièces.

  • Maintenant, vous ne pouvez pas utiliser un point dans les noms de variables. De même, vous ne pouvez pas utiliser les caractères '@', '$', '?' dans les noms de variables.

  • Les exigences relatives à la fonction de démarrage ont été renforcées. Auparavant, vous pouviez spécifier des paramètres dans la fonction de démarrage. Maintenant, tous les points d'entrée init, start, deinit, OnInit, OnStart, OnTick, OnTimer, etc. doivent correspondre exactement à leur signature.

  • En raison de l'expansion du jeu de mots-clés, des noms tels que short, long, float, const, virtual, input, delete, new, do, char ne peuvent plus être utilisés.

  • Les fonctions dll importées ne peuvent plus accepter des tableaux de chaînes de caractères comme paramètre. Dans le mot MQL5

  • Des noms de variables prédéfinis _Period, _Symbol, _LastError, _CriticalError, _StopFlag, _Point, _Digits, _UninitReason, _RandomSeed sont apparus, qui peuvent entrer en conflit avec des variables simples déclarées dans le code source existant avec les mêmes noms.

  • Le type datetime est devenu 8 octets, comme dans MQL5.

Les différences ne sont pas fatales, et peuvent facilement être corrigées dans le code. Au lieu de cela, on dispose de nombreuses fonctionnalités de MQL5, d'une vitesse d'exécution plus rapide et d'un contrôle de qualité beaucoup plus strict.

En rouge, j'ai souligné les plus désagréables.
 
Barbarian:
Je suis bien sûr favorable à l'inclusion de la POO, mais elle est mise en œuvre dans la dll et il n'est pas nécessaire d'entamer une farce dans une nouvelle édition du langage en tant que nouvelle norme.

Je pense que rien n'aurait dû changer dans Mql4 du tout. Il a existé inchangé pendant de nombreuses années, tous les maux ont été guéris et les utilisateurs se sont habitués. L'essentiel est qu'il s'agissait d'un langage très simple et unique avec ses propres caractéristiques, par exemple, il permettait un certain libre arbitre, ce qui pouvait économiser de nombreuses lignes de code. La seule chose qui lui manque vraiment, ce sont les structures. Vous auriez pu vous limiter à les ajouter, et c'est tout. Et MQL5, avec sa sévérité et ses limitations ennuyeuses, n'est plus aussi intéressant, car, comme Barbarian l'a justement fait remarquer, il est beaucoup plus facile de coder en vrai C++ avec des possibilités beaucoup plus larges.

En bref, la meilleure solution serait de laisser MQL4 tel quel et d'ajouter MQL5 en tant que langage distinct dans MT4 (seul l'ensemble des fonctionnalités sera différent de MT5). L'utilisateur déciderait lui-même de la langue dans laquelle il souhaite écrire.

Raison: