新しいMQL4コンパイラとエディタを含むMetaTrader 4 IDEのベータ版 - ページ 5 123456789101112...23 新しいコメント Степан Захватов 2013.09.18 07:45 #41 これほど些細な最適化の提案を見つけるのは難しいかもしれませんが、結局のところ、「市場概要」リストの出力をアルファベット順に整理する時期が来ているのかもしれません。それとも、私の中のエンジニアが、すべては平行・垂直になるべきだと言っているのか......。ストレスはないけれど、幸せでもない。その90％の既成関数に、もう2、3行追加してもいいかもね？ Vadim Zhunko 2013.09.18 15:17 #42 Zaxvatov: これほど些細な最適化の提案を見つけるのは難しいかもしれませんが、結局のところ、「市場概要」リストの出力をアルファベット順に整理する時期が来ているのかもしれません。それとも、私の中のエンジニアが、すべては平行・垂直になるべきだと言っているのか......。ストレスはないけれど、幸せでもない。その90％の既成関数に、もう2、3行追加してもいいかもね？ そのためのアプリが ある。でも、ボタンがあればもっといいんですけどね...。 Alexey Navoykov 2013.09.18 23:14 #43 VOLDEMAR: Question : 新しいmtはいつ？ 待ち遠しい......。 一体何を待っているのでしょうか？新しいバグ？(このような大きな変化は避けられませんが）。一瞬で動かなくなるコードを全部書き換えてデバッグしたくてウズウズしていませんか？自由な時間はないのか？ 個人的には、最近のビルドの混乱で、このようなMQLプログラミングの展望をグローバルに考えるようになりました。しかも、4でも5でもいいんです。本質は同じです。トレーディング・プラットフォームと結びついた特定の合成言語でプログラムを書くと、最終的にはプラットフォームや言語開発者のあらゆる気まぐれやエラーの人質になってしまうのです。今日はMQL4とMQL5を掛け合わせたい、明日はMQL6を掛け合わせたい、などなど。 そして、選択の余地はなく、新しいルールに従って開発をやり直すことを余儀なくされるのです。そうしないと、すべてが動かなくなります。といった具合に、延々と続くのです。全部本気じゃないんです。 一般的に、これは私が持っているすべてのMQLプログラムを、特定の取引プラットフォームに縛られることなく独立したプログラミング環境に移行させるための最後の一押しでした。そして、MQLはあくまでもMTと私のプログラムをつなぐものとして使うつもりです。 そして、これが唯一の正しい方法なのでしょう。 もちろん、開発したものをマーケットで販売するのであれば話は別ですが）。 また、MQLでプログラミングするのが好きなだけで、新しい機能（スポーツの面白さなど）を求めているのであれば、これらがすでに実装されているP5でコーディングすることを妨げるものはないでしょう。 barbarian 2013.09.19 02:30 #44 Meat: 一体何を待っているのでしょうか？バグが増えた？(このような大きな変化は避けられませんが）。すぐに動かないコードを全部書き換えてデバッグしたくてウズウズしていませんか？自由な時間はないのか？ 個人的には、最近のビルドの混乱で、このようなMQLプログラミングの展望をグローバルに考えるようになりました。しかも、4でも5でもいいんです。本質は同じです。トレーディング・プラットフォームと結びついた特定の合成言語でプログラムを書くと、最終的にはプラットフォームや言語開発者のあらゆる気まぐれやエラーの人質になってしまうのです。今日はMQL4とMQL5を掛け合わせたい、明日はMQL6を掛け合わせたい、などなど。 そして、選択の余地はなく、新しいルールに従って開発をやり直すことを余儀なくされるのです。そうしないと、すべてが動かなくなります。といった具合に、延々と続くのです。全部本気じゃないんです。 一般的に、これは私が持っているすべてのMQLプログラムを、特定の取引プラットフォームに縛られることなく独立したプログラミング環境に移行させるための最後の一押しでした。そして、MQLはあくまでもMTと私のプログラムをつなぐものとして使うつもりです。 そして、これが唯一の正しい方法なのでしょう。 もちろん、開発したものをマーケットで販売するのであれば話は別ですが）。 もし、あなたがMQLでプログラミングするのが好きで、新しい機能（スポーツの面白さなど）が欲しいだけなら、これらがすでに実装されているP5でコーディングすることを妨げるものはないでしょう。 開発者が古いビルドのサポートを残し、少なくとも500、新しいビルドへの強制アップグレードを削除するならば、私は同意しますが、それは別の理解できない動き開発者である。もちろん、OOPの搭載は支持しますが、DLLで簡単に実装できますし、新バージョンの言語を新標準として火種を作る必要はないでしょう。例えば、同じC++でも、既存の規格がいくつかあるそうですが、一般的にはどのようなコードの実装でも通用する共通の基盤があるそうです。 Vladimir Pastushak 2013.09.19 13:02 #45 Barbarian: 開発者が古いビルドのサポートを残し、少なくとも500、新しいビルドへの強制アップグレードを削除するならば、私は同意しますが、それは別の理解できない動き開発者である。もちろん、OOPの搭載は支持しますが、DLLで簡単に実装できますし、新バージョンの言語を新標準として火種を作る必要はないでしょう。例えば、同じC++でも、既存の規格がいくつかあるそうですが、一般的にはどのようなコードの実装でも通用する共通基盤があるそうです。 鋳鉄製のアイロンでアイロンをかけ、石炭で調理器を加熱しているのではと疑ってしまいますが． イノベーションは、通貨市場は非常にダイナミックであり、あなたが何かを達成したい場合は、常にトレンドにする必要があるだけでなく、良いです...新たな好転を期待して． Alexey Navoykov 2013.09.19 15:52 #46 VOLDEMAR: イノベーションは、通貨市場は非常にダイナミックであり、あなたが何かを達成したい場合は、常にトレンドにする必要があるだけでなく、良いです...新たな好転を期待して．自分自身が "トレンド "であることと、過去のデザインが "トレンド "になることは別物です。 たくさん持っていない、あるいは価値のないものであれば、問題ないでしょう。しかし、ここにいる多くの人は、何年もかけて書き、デバッグしてきた膨大なコードベースを蓄積しています。そして今、このコードのかなりの部分が間もなく機能しなくなるという事実を前にして、誰もが不安を抱えている。これはナンセンスだ。このような場合、後方互換性、つまり古いバージョンの言語をサポートすることが常に想定されるが、メタクォートではそれができない。 Рустам 2013.09.19 16:05 #47 Meat: 自分自身が "トレンド "であることと、過去のデザインが "トレンド "になることは別物です。 たくさん持っていない、あるいは価値のないものであれば、問題ないでしょう。しかし、ここにいる多くの人は、何年もかけて書き、デバッグしてきた膨大なコードベースを蓄積しています。そして今、このコードのかなりの部分がまもなく動かなくなるという事実を前にして、誰もが不安を抱えている。これはナンセンスだ。このような場合、常に後方互換性、つまり古いバージョンの言語への対応が想定されますが、メタクォートではそのようなことはありません。 本当にそうでしょうか？これはインサイダーなのか？ Artyom Trishkin 2013.09.19 16:08 #48 Meat: 自分自身が "トレンド "であることと、過去のデザインが "トレンド "になることは別物です。 たくさん持っていない、あるいは価値のないものであれば、問題ないでしょう。しかし、ここにいる多くの人は、何年もかけて書き、デバッグしてきた膨大なコードベースを蓄積しています。そして今、このコードのかなりの部分が間もなく機能しなくなるという事実を前にして、誰もが不安を抱えている。これはナンセンスだ。このような場合、常に後方互換性、つまり古いバージョンの言語への対応が想定されますが、メタクォートではそのようなことはありません。 警鐘を鳴らす者の言葉。メタクオーツは何度も言っていますし、おそらく繰り返しても飽きないと思いますが、完全な互換性があることです。もう幼稚なことはやめてください。 Vadim Zhunko 2013.09.19 16:16 #49 FAQ: 本当にそうでしょうか？これはインサイダーなのか？ artmedia70 です。 警鐘を鳴らす者の言葉。メタクオーターは何度も言っているし、おそらく繰り返しても飽きないだろうが、完全な互換性があるのだろう。もう子供じみたことはやめてくれないか？ ここでは、完全互換と言われないように、強調表示しました。 レナート 旧バージョンのMQL4との違いは何でしょうか。 ブーリアン演算のAND/OR演算の優先順位が変更されました。これで、すべてが古典的なC/C++と同じになりました。 論理式の評価を短縮する機能が導入されました。論理式を評価する際に、残りの部分式は評価されないようになりました。C/C++のように。 switch演算子が整数値のみを使用するようになりました。以前は本物を使うことができました。 さて、変数名にはフルストップは使えません。また、変数名に '@', '$', '?' を使用することはできません。 スタート機能への要求事項が厳しくなりました。従来は、スタート関数の中でパラメータを指定することができました。これで、すべてのエントリポイント init, start, deinit, OnInit, OnStart, OnTick, OnTimer などは、そのシグネチャに正確に一致する必要があります。 キーワードセットの拡張により、short, long, float, const, virtual, input, delete, new, do, char などの名称は使用できなくなりました。 インポートされたDLL関数は、パラメータとして文字列の配列を受け付けないようになりました。MQL5と同様 あらかじめ定義された変数名_Period, _Symbol, _LastError, _CriticalError, _StopFlag, _Point, _Digits, _UninitReason, _RandomSeedが登場し、既存のソースコードで同名で宣言された単純変数と競合する可能性があること。 datetime型は、MQL5と同様に8バイトになりました。 この違いは致命的なものではなく、コードの中で簡単に修正することができます。 その代わり、MQL5の多くの機能、より速い実行速度、より厳密な品質管理が利用可能です。 赤色で、最も不快なものを強調しました。 Alexey Navoykov 2013.09.19 16:44 #50 Barbarian: もちろん、私はOOPの搭載を支持しますが、それはDLLで実装するものであり、新たな標準として言語のバージョンを作る必要はありません。Mql4では何も変えるべきではなかったと思います。長年変わらずに存在し、すべての病気が治り、ユーザーが慣れた。例えば、自由な発想が可能で、コードの行数を減らすことができるなど、独自の特徴を持った非常にシンプルでユニークな言語であったことが大きな特徴です。ただ、構造物だけは、本当に足りなかった。追加するだけにとどめておけばよかったのに。 そして、MQL5は、そのつまらない厳しさと制限のために、もうあまり面白くありません。Barbarianが正しく指摘したように、本当のC++でコーディングする方がはるかに簡単で、より広い可能性を持っているからです。 要するに、MQL4はそのままにして、MT4に別言語としてMQL5を追加する（機能セットのみMT5と異なる）のがベストな解決策でしょう。どの言語で書くかは、ユーザーが自分で決めることになる。 123456789101112...23 新しいコメント 理由: キャンセル 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
これほど些細な最適化の提案を見つけるのは難しいかもしれませんが、結局のところ、「市場概要」リストの出力をアルファベット順に整理する時期が来ているのかもしれません。それとも、私の中のエンジニアが、すべては平行・垂直になるべきだと言っているのか......。ストレスはないけれど、幸せでもない。その90％の既成関数に、もう2、3行追加してもいいかもね？
Question : 新しいmtはいつ？ 待ち遠しい......。
一体何を待っているのでしょうか？新しいバグ？(このような大きな変化は避けられませんが）。一瞬で動かなくなるコードを全部書き換えてデバッグしたくてウズウズしていませんか？自由な時間はないのか？
個人的には、最近のビルドの混乱で、このようなMQLプログラミングの展望をグローバルに考えるようになりました。しかも、4でも5でもいいんです。本質は同じです。トレーディング・プラットフォームと結びついた特定の合成言語でプログラムを書くと、最終的にはプラットフォームや言語開発者のあらゆる気まぐれやエラーの人質になってしまうのです。今日はMQL4とMQL5を掛け合わせたい、明日はMQL6を掛け合わせたい、などなど。 そして、選択の余地はなく、新しいルールに従って開発をやり直すことを余儀なくされるのです。そうしないと、すべてが動かなくなります。といった具合に、延々と続くのです。全部本気じゃないんです。
一般的に、これは私が持っているすべてのMQLプログラムを、特定の取引プラットフォームに縛られることなく独立したプログラミング環境に移行させるための最後の一押しでした。そして、MQLはあくまでもMTと私のプログラムをつなぐものとして使うつもりです。 そして、これが唯一の正しい方法なのでしょう。 もちろん、開発したものをマーケットで販売するのであれば話は別ですが）。
また、MQLでプログラミングするのが好きなだけで、新しい機能（スポーツの面白さなど）を求めているのであれば、これらがすでに実装されているP5でコーディングすることを妨げるものはないでしょう。
一体何を待っているのでしょうか？バグが増えた？(このような大きな変化は避けられませんが）。すぐに動かないコードを全部書き換えてデバッグしたくてウズウズしていませんか？自由な時間はないのか？
個人的には、最近のビルドの混乱で、このようなMQLプログラミングの展望をグローバルに考えるようになりました。しかも、4でも5でもいいんです。本質は同じです。トレーディング・プラットフォームと結びついた特定の合成言語でプログラムを書くと、最終的にはプラットフォームや言語開発者のあらゆる気まぐれやエラーの人質になってしまうのです。今日はMQL4とMQL5を掛け合わせたい、明日はMQL6を掛け合わせたい、などなど。 そして、選択の余地はなく、新しいルールに従って開発をやり直すことを余儀なくされるのです。そうしないと、すべてが動かなくなります。といった具合に、延々と続くのです。全部本気じゃないんです。
一般的に、これは私が持っているすべてのMQLプログラムを、特定の取引プラットフォームに縛られることなく独立したプログラミング環境に移行させるための最後の一押しでした。そして、MQLはあくまでもMTと私のプログラムをつなぐものとして使うつもりです。 そして、これが唯一の正しい方法なのでしょう。 もちろん、開発したものをマーケットで販売するのであれば話は別ですが）。
もし、あなたがMQLでプログラミングするのが好きで、新しい機能（スポーツの面白さなど）が欲しいだけなら、これらがすでに実装されているP5でコーディングすることを妨げるものはないでしょう。
開発者が古いビルドのサポートを残し、少なくとも500、新しいビルドへの強制アップグレードを削除するならば、私は同意しますが、それは別の理解できない動き開発者である。もちろん、OOPの搭載は支持しますが、DLLで簡単に実装できますし、新バージョンの言語を新標準として火種を作る必要はないでしょう。例えば、同じC++でも、既存の規格がいくつかあるそうですが、一般的にはどのようなコードの実装でも通用する共通基盤があるそうです。
鋳鉄製のアイロンでアイロンをかけ、石炭で調理器を加熱しているのではと疑ってしまいますが． イノベーションは、通貨市場は非常にダイナミックであり、あなたが何かを達成したい場合は、常にトレンドにする必要があるだけでなく、良いです...新たな好転を期待して．
イノベーションは、通貨市場は非常にダイナミックであり、あなたが何かを達成したい場合は、常にトレンドにする必要があるだけでなく、良いです...新たな好転を期待して．
自分自身が "トレンド "であることと、過去のデザインが "トレンド "になることは別物です。 たくさん持っていない、あるいは価値のないものであれば、問題ないでしょう。しかし、ここにいる多くの人は、何年もかけて書き、デバッグしてきた膨大なコードベースを蓄積しています。そして今、このコードのかなりの部分が間もなく機能しなくなるという事実を前にして、誰もが不安を抱えている。これはナンセンスだ。このような場合、後方互換性、つまり古いバージョンの言語をサポートすることが常に想定されるが、メタクォートではそれができない。
自分自身が "トレンド "であることと、過去のデザインが "トレンド "になることは別物です。 たくさん持っていない、あるいは価値のないものであれば、問題ないでしょう。しかし、ここにいる多くの人は、何年もかけて書き、デバッグしてきた膨大なコードベースを蓄積しています。そして今、このコードのかなりの部分がまもなく動かなくなるという事実を前にして、誰もが不安を抱えている。これはナンセンスだ。このような場合、常に後方互換性、つまり古いバージョンの言語への対応が想定されますが、メタクォートではそのようなことはありません。
本当にそうでしょうか？これはインサイダーなのか？
自分自身が "トレンド "であることと、過去のデザインが "トレンド "になることは別物です。 たくさん持っていない、あるいは価値のないものであれば、問題ないでしょう。しかし、ここにいる多くの人は、何年もかけて書き、デバッグしてきた膨大なコードベースを蓄積しています。そして今、このコードのかなりの部分が間もなく機能しなくなるという事実を前にして、誰もが不安を抱えている。これはナンセンスだ。このような場合、常に後方互換性、つまり古いバージョンの言語への対応が想定されますが、メタクォートではそのようなことはありません。
本当にそうでしょうか？これはインサイダーなのか？
警鐘を鳴らす者の言葉。メタクオーターは何度も言っているし、おそらく繰り返しても飽きないだろうが、完全な互換性があるのだろう。もう子供じみたことはやめてくれないか？
ここでは、完全互換と言われないように、強調表示しました。
旧バージョンのMQL4との違いは何でしょうか。
ブーリアン演算のAND/OR演算の優先順位が変更されました。これで、すべてが古典的なC/C++と同じになりました。
論理式の評価を短縮する機能が導入されました。論理式を評価する際に、残りの部分式は評価されないようになりました。C/C++のように。
switch演算子が整数値のみを使用するようになりました。以前は本物を使うことができました。
さて、変数名にはフルストップは使えません。また、変数名に '@', '$', '?' を使用することはできません。
スタート機能への要求事項が厳しくなりました。従来は、スタート関数の中でパラメータを指定することができました。これで、すべてのエントリポイント init, start, deinit, OnInit, OnStart, OnTick, OnTimer などは、そのシグネチャに正確に一致する必要があります。
キーワードセットの拡張により、short, long, float, const, virtual, input, delete, new, do, char などの名称は使用できなくなりました。
インポートされたDLL関数は、パラメータとして文字列の配列を受け付けないようになりました。MQL5と同様
この違いは致命的なものではなく、コードの中で簡単に修正することができます。 その代わり、MQL5の多くの機能、より速い実行速度、より厳密な品質管理が利用可能です。
もちろん、私はOOPの搭載を支持しますが、それはDLLで実装するものであり、新たな標準として言語のバージョンを作る必要はありません。
Mql4では何も変えるべきではなかったと思います。長年変わらずに存在し、すべての病気が治り、ユーザーが慣れた。例えば、自由な発想が可能で、コードの行数を減らすことができるなど、独自の特徴を持った非常にシンプルでユニークな言語であったことが大きな特徴です。ただ、構造物だけは、本当に足りなかった。追加するだけにとどめておけばよかったのに。 そして、MQL5は、そのつまらない厳しさと制限のために、もうあまり面白くありません。Barbarianが正しく指摘したように、本当のC++でコーディングする方がはるかに簡単で、より広い可能性を持っているからです。
要するに、MQL4はそのままにして、MT4に別言語としてMQL5を追加する（機能セットのみMT5と異なる）のがベストな解決策でしょう。どの言語で書くかは、ユーザーが自分で決めることになる。