Suggestions pour la syntaxe MQL - page 10

Nouveau commentaire
 
C'est drôle de lire tout ça. Je me souviens des cris des anciens camarades lorsqu'ils ont décidé d'introduire les classes, les "pointeurs" et les structures dans MQL. Ils avaient l'habitude d'écrire : "Vous avez tué le MQL ! Maintenant, seuls les professionnels pourront y écrire...". - et autres bêtises. Maintenant, ils crient de l'autre côté : laissez-moi avoir un C++ complet alors que le méga-système est impossible à coder. Mais qui vous empêche de le faire ? Prenez C++ et continuez votre chemin. Le MQL est un peu une autre histoire et il est naïf de mélanger le chaud et le froid.
 

Que dites-vous de C++... Si vous n'aimez pas C++, prenez C#. Je l'ai spécifiquement mentionné dans mon message original et plus loin dans les discussions, je l'ai souligné. Beaucoup des choses suggérées concernent les deux langages.

Donc, de deux choses l'une : soit vous êtes contre le progrès par principe, soit vous ne faites que râler. Bien que les deux variantes soient également possibles

 
Alexey Navoykov:

...

MetaTrader est un bon terminal. Mais malheureusement, la grande majorité de ses utilisateurs sont encore des perdants et des joueurs. MQ a fait un très gros effort pour se lancer dans le créneau du trading intelligent, mais il n'a pas réussi. Les parieurs n'ont besoin que d'un MT4 "poke" avec un "TrendLaser" multicolore sur le graphique. Ils se moquent des structures, des classes, des spécialités avec déclinaison, etc. Mais "un mouton molletonné d'un mouton maigre" - c'est ainsi que nous vivons. Par conséquent, dans cette situation, il n'est pas économiquement faisable de développer des fonctionnalités linguistiques dans MQL5. Mais il serait raisonnable de flirter avec la foule, par exemple introduire des verrous dans MT5 ou Open[0] au lieu de CopyRates.

 

En fait, c'est un peu étrange. À l'origine, MQL a été créé comme un langage d'application pour l'écriture de stratégies de trading. Par conséquent, il ne contenait pas tout ce que le C++ possède. Mais au fil du temps, les tâches du trading algorithmique sont devenues plus compliquées, et les gens cherchent et attendent des ajouts au langage. Ainsi, ils ont tendance à y mettre tout ce qui n'a pas été ajouté intentionnellement. Ce faisant, le nombre de règles et le niveau de complexité de la langue augmenteront, devenant une barrière pour eux-mêmes. Mais, s'ils sont prêts à les surmonter, rien ne les arrêtera.

Pour moi, le développement consiste avant tout à trouver le moyen le plus simple et le plus efficace de mettre en œuvre une idée. En tant que tel, les capacités de l'ancien langage sont suffisamment bonnes, mais les programmeurs professionnels ont la nostalgie de l'amoncellement de règles et des piles de syntaxe. )) Si cela leur donne de l'inspiration, pourquoi pas ?

 
Реter Konow:

Dans le même temps, le nombre de règles et le niveau de complexité de la langue augmenteront, devenant une barrière pour eux.

Pourquoi une barrière ? L'ajout de nouvelles fonctionnalités n'empêche pas d'utiliser les anciennes. En règle générale, personne n'est obligé d'utiliser ces "complexités".

Certes, il y a eu des périodes où les règles établies ont été soudainement et impitoyablement modifiées au profit du C++, mais c'était l'époque de son développement rapide. Aujourd'hui, le langage possède presque tout et il ne reste que de petites modifications.

 

Au fait, je ressens personnellement non seulement un manque d'améliorations, mais aussi une réduction des fonctionnalités de la langue au cours de la dernière année et demie. La build la plus fonctionnelle et la plus stable était la 1554, datée du 14 mars 2017.Après cela, il y a eu une refonte radicale des composants internes, et il y a eu des versions problématiques avec de nombreux bogues, dont certains n'ont pas été corrigés à ce jour. Cependant, certains des anciens bogues ont été corrigés. En général, le niveau de bogues des versions actuelles est probablement légèrement meilleur. Mais en ce qui concerne la fonctionnalité...

Par exemple, j'ai déjà écrit sur la suppression de la possibilité de convertir des tableaux en types de base. Une autre suppression a été l'interdiction de convertir des structures simples entre elles. Oui, elles ont été remplacées par des unités, mais elles ne couvrent pas les possibilités offertes par la conversion qui permettait de compenser les inconvénients de la fonctionnalité régulière. Étant donné que MQL n'a pas d'interfaces pour les structures (j'ai déjà écrit à ce sujet), cette solution était une bonne alternative :

template<typename T>
struct IValueable
{ 
  double Value() const { return ((T)this).GetValue(); }
 protected:
  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

  A(double value) { _value=value; }
  
  double GetValue() const { return _value; }
};


void Func(IValueable<A> &a) { Print(a.Value()); }


void OnStart()
{
  A a(10);
  Func(a);
}
 
Alexey Navoykov:

Pourquoi une barrière ? L'ajout de nouvelles fonctionnalités ne vous empêche pas d'utiliser les anciennes. En règle générale, personne n'est obligé d'utiliser ces "complexités".

Bien sûr, il est arrivé que des règles bien établies soient soudainement réécrites sans pitié au nom du C++, mais c'était à l'époque de son développement rapide. Aujourd'hui, nous avons presque tout et il ne reste que de petites modifications.

Je voulais dire une barrière pour ceux qui veulent utiliser les nouvelles règles et la nouvelle syntaxe par eux-mêmes. Ils devront écrire leurs programmes plus longtemps et prendre plus de temps pour les comprendre. Cela rendra-t-il leurs programmes plus efficaces ? - Pas vraiment. Seront-ils capables de résoudre un plus grand nombre de tâches ? - Pas vraiment.

J'ai un jour proposé sur un forum une solution très simple pour une tâche que tout le monde avait l'habitude de résoudre avec une montagne de code. C'était petit et rapide. Cependant, tout le monde n'a pas aimé. Il n'y avait pas ces choses qu'ils aimaient. Toutes sortes demodèles<typename T> etvoid Func(IValueable<A> &a)

On m'a proposé de les utiliser tous. Lorsque j'ai demandé "pourquoi ?", personne n'a expliqué clairement quoi que ce soit.


P.S. L'explication la plus claire que j'ai reçue était : "Votre code est laid". Et autre chose : "Vous ne comprenez pas le pouvoir conceptuel". Mais je suis un développeur. J'ai besoin d'une belle solution, pas d'un beau code.

 
Alexey Navoykov:

Certes, ils ont été remplacés par des unions, mais ils ne couvrent pas les possibilités offertes par la conversion, qui a permis de pallier les lacunes de la fonctionnalité standard. Étant donné que MQL ne fournit pas d'interfaces pour les structures (j'ai déjà écrit à ce sujet), cette solution était une bonne alternative :

Cela se compile.

#include <TypeToBytes.mqh>

template<typename T>
struct IValueable
{ 
  uchar Tmp;
  double Value() const { return (_C(T, this)).GetValue(); }
 protected:
//  IValueable() { }
 private:
  static void Check_IValueable() { T::Check_IValueable(); }  // Дополнительная проверка, гарантирующая наследование T от нашей структуры
};

struct A : IValueable<A>
{ 
  double _value;

//  A(double value) { _value=value; }
  void Set( double value ) { _value=value; }
  
  double GetValue() const { return _value; }
};

Mais le résultat, bien sûr, est différent.

1...345678910
Nouveau commentaire