MQL構文に関する提案 - ページ 10

新しいコメント
 
これだけ読むと面白いですね。MQLにクラスや「ポインタ」、構造体を導入することになったとき、昔の同志が叫んだのを覚えています。昔は「MQLを殺したのはお前だ！」と書かれていました。これでプロしか書けなくなる...」と。- などと意味不明なことを言っています。今、彼らは反対側から叫んでいます：メガシステムがコーディング不可能な間、フル機能のC++を持たせてくれ、と。しかし、それを阻むのは誰なのか？C++を手に取り、旅に出よう。MQLはちょっと別物で、温故知新を混ぜるのは甘えなんです。
 

C++について何を言っているのか...C++が嫌ならC#をとればいい。 私は最初の投稿で特にそのことに触れ、さらに議論の中で下線を引いた。 提案されたことの多くは、両方の言語に関するものだ。

つまり、原則的に進歩に反対なのか、それともただ不平不満があるのか、2つのうちのどちらかです。 両方のバリエーションも可能ですが。

 
Alexey Navoykov:

...

MetaTraderは良いターミナルです。しかし、残念ながら、そのユーザーの大半はまだ負け組、ギャンブラーです。MQはスマートトレーディングのニッチに進出するために非常に大きな努力をしたが、成功しなかった。ギャンブラーは、チャート上にマルチカラーの「TrendLaser」を搭載したMT4を「突く」だけでいいのです。しかし、「薄っぺらい羊の綿毛」、それが私たちの生き方なのです。したがって、このような状況では、MQL5で言語機能を開発することは経済的に不可能なのです。しかし、例えばMT5でロックを導入したり、CopyRatesの 代わりにOpen[0]を導入するなど、群衆とたわむれることは合理的でしょう。

 

実は、これはちょっと不思議なことなんです。もともとMQLは、トレーディングストラテジーを書くためのアプリケーション言語として作られたものです。そのため、C++が持っているものをすべて含んでいたわけではありません。しかし、時が経つにつれ、アルゴリズム取引におけるタスクはより複雑になり、人々は言語への追加を探し、待ち望んでいます。したがって、意図的に加えなかったものをすべて入れてしまう傾向がある。そうすると、ルールの数や言語の複雑度が増し、自分たちの障害になる。しかし、それを乗り越えようとする意志があれば、止めることはできない。

私にとっての開発とは、まず第一に、思考を実現するための正しい方法、最も簡単な方法を見つけることです。このように、古い言語の能力でも十分なのだが、プロのプログラマーは、ルールの山、シンタックスの山にノスタルジーを感じてしまうのである。))まあ、それがインスピレーションになるなら、いいんじゃないでしょうか。

 
Реter Konow:

同時に、ルールの数や言語の複雑さのレベルも上がり、彼らの障壁となる。

なぜ障壁があるかというと、新しい機能を追加しても、古い機能が使えなくなるわけではありません。この「コンプレックス」を無理に利用することは、原則としてありません。

確かに、C++のために既成のルールを突然容赦なく変えた時期もあったが、それはC++が急速に発展した時期であり、今ではほとんどすべてを手に入れ、小さな修正しか残されていないのだ。

 

ところで、個人的にはこの1年半、改善不足だけでなく、言語機能の縮小も感じています。 最も機能的で安定したビルドは、2017年3月14日付の1554です。その後、内部構造の抜本的な見直しが行われ、多くのバグを抱えた問題のあるビルドが存在し、その一部は現在も修正されていません。 しかし、古いバグの一部は修正されています。 一般的に、バグのレベルは現在のビルドが若干勝っていると思われます。 しかし、機能性については......。

例えば、配列を基本型にキャストする可能性がなくなったことはすでに書きました。 また、単純な構造 体を相互にキャストすることが禁止されました。 確かに、それらはユニットに置き換えられましたが、通常の機能の欠点を補うことができたキャストによって与えられた可能性をカバーするものではありません。MQLには構造体に対するインターフェースがない（すでに書きました）ことを考えると、この解決策は良い代替案でした。

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:

なぜ障壁があるのか？ 新機能を追加しても、旧機能が使えなくなるわけではありません。この「コンプレックス」を無理に利用することは、原則としてありません。

もちろん、確立されたルールがC++のために突然容赦なく書き換えられたこともありましたが、それはC++が急速に発展した時代です。 今では、ほとんどすべてが揃い、少しの修正を加えるだけでよくなりました。

新しいルールや構文を自力で使いこなそうとする人へのバリアという意味です。プログラムを書く時間が長くなり、理解するのに時間がかかるようになる。これでプログラムの効率が上がるのでしょうか？- そうでもないんです。より多くの課題を解決できるようになるのでしょうか？- そうでもないんです。

以前、あるフォーラムで、誰もが山のようなコードで解決していたタスクを、非常にシンプルな方法で解決する方法を提案したことがあります。小さくて速い。しかし、みんなには不評でした。そういう自分たちの好きなものがなかったんです。あらゆる種類のテンプレート<typename T> とvoid Func(IValueable<A> & a)

全部使ってくださいと言われたんです。と聞いても、誰も明確な説明をしてくれない。


P.S. 私が受けた最も明確な説明は、「あなたのコードは醜い」というものでした。そしてもうひとつ、「あなたは構想力を理解していない」。でも、私は開発者です。美しいコードではなく、美しいソリューションが必要なのです。

 
Alexey Navoykov:

確かにユニオンに置き換えられましたが、標準機能の欠点を補うことができた変換によってもたらされた可能性をカバーするものではありません。MQLが構造体のインターフェースを提供していないことを考えると（それについてはすでに書きました）、この解決策は良い代替案でした。

これはコンパイルします。

#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; }
};

しかし、結果はもちろん違う。

1...345678910
新しいコメント