私見ですが、これだけのものが必要な人はほとんどいないのではないでしょうか。
Kodobaseのコードから判断すると、95%のユーザーはOOPをほとんど使っていません。そして、残り5%のマジョリティのうち、これらの機能はほとんど使われていない。確かにそれらは楽しいし、便利でもあるのですが、これらの改良に大きな必要性はないと私は考えています。
私見ですが、これだけのものが必要な人はほとんどいないのではないでしょうか。
Kodobaseのコードから判断すると、95%のユーザーはOOPを非常にうまく使っていません。そして、残りの5%のうち、ほとんどの人がこれらの機能をあまり使っていないのです。もちろん、それらは楽しいものですし、便利なものでもありますが、私が思うに、これらの改良に大きな必要性はないでしょう。
そうですね、でもkodobaseの他にFreelanceやMarketがあり、そこではMQは製品の品質に関心があるはずです。 そして言語の品質は、開発やデバッグの品質やスピードに何らかの形で影響を及ぼしますね。
そんなこと言ってたら、そもそもMQL5ってなんでできたんだろう。 OOPとか必要ない古いハードコアなMQL4のままなんだけど......。99%のユーザーが満足している )
おそらく普通のプログラマーは、まだ不完全な言語であるからこそ、MQLに行かないのでしょう。
私の観察によると、MQLの構文の開発は長い間停滞しており、過去数年間は言語に改善が見られませんでした。 開発者がさらにMQLに取り組むつもりかどうかは分かりませんが、多くの機能が非常に不足しており、その中には決定的に必要なものも含まれています。
このスレッドでは、私の主な要望をリストアップすることにしました。 まず私がリストをあげ、おそらく誰かが他のものを追加し、その後、開発者が参加してビジョンを共有することができれば、それは素晴らしいことだと思います。
このリストは重要性の高い順に並べましたが、私個人の優先順位ではありません。 つまり、言語にとって最も基本的で不可欠なものを最初に並べました。C++やC#の機能をベンチマークとする
1.型を扱う:typedef,decltype,auto
これは、少なくとも最初の2つの指定子については、実は基本的な機能なのです。 ネーミングや型ホッピングの操作は、利便性だけでなく、コードの信頼性や柔軟性のために作られています。 異なる場所で使われる具体的な変数の型に固定値を設定すると、いずれかの型を変更する必要があるときに問題が発生します。
typedefについては、すでにご存知の方も多いと思うが、残念ながらまだ関数ポインタでしか使えない切り札である。decltypeについては、ご存じない方のために説明すると、引数として渡された式の型を返すので、他の型に基づいて変数や関数の型を柔軟に定義することが可能である。
typedefを使うか、どちらかです。
C#ではtypedefの代わりにusingが 使用される。
2.名前空間:namespace
このテーマは、すでに最近議論されています。私にとっては、この言語の必須機能であるにもかかわらず、なぜまだ実装されていないのか本当に不思議です。特に、コミュニティ、コードベース、グループ開発といった流れを考えると、なおさらです。この場合、名前のマッチングの問題が非常に重要になってきます。
一般的に、1つのスペースにすべてを一山にするのは間違っています。
これがないと、ユーザー定義 型は本質的に不完全なものとなり、柔軟性が大きく損なわれてしまうのです。
通常は、コンストラクタをオーバーロードし、対応する型にキャストすることで、この型と構造体の完全な互換性を得ることができます。
しかし、MQLでは、その代わりに、別のメソッドto_datetime() を作成し、その呼び出しをあらゆる場所に記述する必要があります。あるいは、DATETIME & typeのターゲット関数の呼び出しをオーバーロードする必要がありますが、これも快適性と柔軟性を向上させるものではありません。
4.マルチインターフェイス・・・ まあ、すでにいろいろと噂や話は出ているのですが(3年前にサービスデスクで作業中と書いてあったような)、引きずっているんですよね・・・。もし、まったく進行していないのであれば。
5.O OPで統一された作業を行うためには、構造体に対するインタフェースのサポートが 必要です。 現状では、松葉杖を作らなければならないことが多いのです。
この機能は、C#のようにパッケージング/アンパッキング(ボックス化)する方法と、より柔軟な方法として、構造体を含む動的オブジェクトの記述子にリンクした構造体の動的ハンドルを作成する方法の2つが考えられます。
6.構造体を値で渡すことが できます.これは,小さな構造体(上の例では DATETIME)を渡すときに重要で,構造体のコンストラクタがこの型をサポートしていれば,ある型から別の型にその場で柔軟に変換することができます.参照渡しの場合は、そのような柔軟性はなく、構造体用のインタフェースを実装すれば、あまり関係なくなりますが。
7.テンプレートの数値パラメータを指定することができます。
2番目の例については、MQL4では、関数があらゆる次元の配列を受け入れるので、なくても大丈夫です。そしてMQL5では、多次元配列によってすべてがより複雑になっています。
というように、小さなことでも
9.ポインタの配列をベースポインタの配列に(明示的または暗黙的に)キャストすることができる。昔のビルドではこれが有効で、とても便利だったんです。
これで、アレイを新しいものにコピーし直して、また元に戻すという無駄な労力を使うことになりました。
12.ポインタを明示的に数値にキャストすることが可能です。
ポインタの配列を値でソートして、バイナリサーチやハッシュテーブルを作ることで必要なポインタを素早く見つけることができるようになります。 今はテキスト形式に変換することでしか数値を得ることができないので、このアイデア自体が失われてしまっています。
13.デフォルトのテンプレートパラメーターの設定
応援しています。
私の考えでは、これだけのものを必要とする人はごく少数だと思います。
Kodobaseのコードから判断すると、95%のユーザーはOOPをほとんど使っていません。そして、残り5%のマジョリティのうち、これらの機能はほとんど使われていない。もちろん、それらはいいものですし、便利なものでもありますが、これらの改良はあまり必要ないと私は考えています。
この少人数で、みんなが使うようなライブラリを書くことができるのです。
14.関数の引数が 定数参照である場合に、一時的なオブジェクトを渡すことができるようにする。
template< typename Type > struct complex { Type Re; Type Im; complex() : Re(), Im(){} complex( Type re, Type im ) : Re(re), Im(im){} }; template< typename Type > void Func( const Type& val ) { } void OnStart() { Func( 5.0 ); complex< double > C( 1.0, 5.0 ); Func( C ); Func( complex< double >( 2.0, 4.0 ) ); }
15.友人というキーワード
クラスによっては、特定のクラスにのみプライベート・メンバーへのアクセスを許可し、他のクラスには許可しないようにしたい場合があります。
template< typename Type > class Matrix; template< typename Type > class MatrixData { friend class Matrix< Type >; int mRefCount; int mRows; int mColumns; Type mArray[]; public: MatrixData(); MatrixData( int rows, int cols ); }; template< typename Type > class matrix { MatrixData< Type >* mData; public: Matrix(); Matrix( int rows, int cols ); };
16. 組み込み型のコンストラクタを明示的に呼び出す際に、変数を NULL にする。
これは、テンプレートで便利です。
double x; // Не инициализирована double y(); // Инициализирована нулём double z = 5.0; // Инициализирована 5.0
このようなトピックを立てることにしたのは、私の観察によると、MQLの構文開発は長い間停滞しており、ここ数年、言語の改良は行われていません。 開発者がMQLに取り組むかどうかはわかりませんが、多くの機能が本当に欠けており、そのうちのいくつかは非常に必要とされています。
このスレッドでは、主な希望をまとめることにしました。 まず私がリストをあげ、もしかしたら誰かが何かを追加するかもしれません。 そして、開発者たちがつながり、彼らのビジョンを表現してくれたら、それはとても素晴らしいことです。
禁止事項を期待する、経典の批判は許されない :)
PS: 改善は、それほどグローバルなものではありませんでしたが、ありました。
ポインターも持っていない)これ以上基本的なことがあるだろうか)
ないだろう、GCがないとはいえ、言語は管理されているのだから
シャープもアンセーフモードだけにしています。
そうですね、でもkodobaseの他にFreelanceやMarketがあり、そこではMQは製品の品質に関心があるはずです。 そして言語の品質は、開発やデバッグの品質やスピードに何らかの形で影響を及ぼしますね。
そんなこと言ってたら、そもそもMQL5ってなんでできたんだろう。 OOPとか必要ない古いハードコアなMQL4のままなんだけど......。99%のユーザーが満足している )
普通のプログラマーがMQLに行かないのは、まだ未完成な言語だからかもしれません。
コドベースは95%ゴミで全然ダメ。MT5の新バージョンを久しぶりに見た。レナートは、新しいリリースでグローバルな何かを約束したと記憶しています。
PS:改善点は、それほどグローバルなものではありませんでしたが、ありました。
最後に覚えているのは、ダイナミック・オブジェクトのコピーを可能にする暗黙のコピー演算子ですが、特にあれから多くの時間が経過しているため、それは何でもありません。

- 無料取引アプリ
- 8千を超えるシグナルをコピー
- 金融ニュースで金融マーケットを探索
このようなトピックを作ろうと思ったのは、私の観察によると、MQL構文の開発は長い間停滞しており、ここ数年、この言語の改善は見られません。 開発者がMQLに全く取り組む気がないのかどうかは分かりませんが、本当に多くの機能が欠けており、その中には決定的に重要なものも含まれています。
このスレッドでは、私の主な要望をリストアップすることにしました。 まず私がリストをあげ、おそらく誰かが他のものを追加し、その後、開発者が参加してビジョンを共有することができれば、それは素晴らしいことだと思います。
このリストは重要性の高い順に並べましたが、私個人の優先順位ではありません。 つまり、言語にとって最も基本的で不可欠なものを最初に並べました。C++やC#の機能をベンチマークとする
1.型を扱う:typedef,decltype,auto
これは、少なくとも最初の2つの指定子については、実は基本的な機能なのです。 ネーミングや型ホッピングの操作は、利便性だけでなく、コードの信頼性や柔軟性のために作られています。 異なる場所で使われる具体的な変数の型に固定値を設定すると、いずれかの型を変更する必要があるときに問題が発生します。
typedefについては、すでにご存知の方も多いと思うが、残念ながらまだ関数ポインタでしか使えない切り札である。decltypeについては、ご存じない方のために説明すると、引数として渡された式の型を返すので、他の型に基づいて変数や関数の型を柔軟に定義することが可能である。
typedefを使うか、どちらかです。
C#ではtypedefの代わりにusingが 使用される。
2.名前空間:namespace
このテーマは、すでに最近議論されています。私にとっては、この言語の必須機能であるにもかかわらず、なぜまだ実装されていないのか本当に不思議です。特に、コミュニティ、コードベース、グループ開発といった流れを考えると、なおさらです。この場合、名前のマッチングの問題が非常に重要になってきます。
しかも、すべてを一カ所に山積みするのは間違っています。
これがないと、ユーザー定義 型は本質的に不完全なものとなり、柔軟性が大きく損なわれてしまうのです。
通常は、コンストラクタをオーバーロードし、対応する型にキャストすることで、この型と構造体の完全な互換性を得ることができます。
しかし、MQLでは、その代わりに、別のメソッドto_datetime() を作成し、その呼び出しをあらゆる場所に記述する必要があります。あるいは、DATETIME & typeのターゲット関数の呼び出しをオーバーロードする必要がありますが、これも快適性と柔軟性を向上させるものではありません。
4.マルチインターフェイス・・・ まあ、すでにいろいろと噂や話は出ているのですが(3年前にサービスデスクで作業中と書いてあったような)、引きずっているんですよね・・・。もし、まったく進行していないのであれば。
5.O OPで統一された作業を行うためには、構造体に対するインタフェースのサポートが 必要です。 現状では、松葉杖を作らなければならないことが多いのです。
この機能は、C#のようにパッケージング/アンパッキング(ボックス化)する方法と、より柔軟な方法として、構造体を含む動的オブジェクトの記述子にリンクした構造体の動的ハンドルを作成する方法の2つが考えられます。
6.構造体を値で渡すことが できます.これは,小さな構造体(上の例では DATETIME)を渡すときに重要で,構造体のコンストラクタがこの型をサポートしていれば,ある型から別の型にその場で柔軟に変換することができます.参照渡しの場合はこのような柔軟性はないが、構造体用のインタフェースが実装されれば、その意味はなくなる。
7.テンプレートの数値パラメータを指定することができます。
2番目の例については、MQL4では、関数があらゆる次元の配列を受け入れるので、なくても大丈夫です。そしてMQL5では、多次元配列によってすべてがより複雑になっています。
というように、小さなことでも
9.ポインタの配列をベースポインタの配列に(明示的または暗黙的に)キャストすることができる。昔のビルドではこれが有効で、とても便利だったんです。
これで、アレイを新しいものにコピーし直して、また元に戻すという無駄な労力を使うことになりました。
12.ポインタを明示的に数値にキャストすることが可能です。
ポインタの配列を値でソートして、バイナリサーチやハッシュテーブルを作ることで必要なポインタを素早く見つけることができるようになります。 今はテキスト形式に変換することでしか数値を得ることができないので、このアイデア自体が失われてしまっています。
13.デフォルトのテンプレートパラメーターの設定