MQL5ではOOPは需要になるのでしょうか？ - ページ 3

新しいコメント
 

少なくとも、MQL4の学習は無駄にはならないでしょう。標準的なインジケーターだけを使用していた場合、私の理解では、変換はそれほど難しくはないでしょう。

一般のセミプロのプログラマーは、MQL5でOOPは必要ないだろうと思うのですが。

すべての面でスピードが上がるという印象があれば、大きな問題が解決するかもしれない、そんな指標は見たくないですね。繰り返しますが、私はプロではありません。

でも、これからはマニアがMQL5を使って、プライマリーブロスから生命が発生するシミュレーションをするようになるかもしれませんね？;)

P/S 忘れた。イベントハンドリング機能。グッドです。

 
EX5ライブラリは、インターフェース（仮想関数を 持つクラス）を返すという保護効果があるのでしょう。私と「協調しない」使い方をした場合、スタブ・インターフェースを返します（あまり目立たない計算上の欠陥があります）。
 
mql_coder >> :
...ライブラリはインタフェース（仮想関数を持つクラス）を返します。私と「協調しない」使い方をした場合、（あまり目立たない計算上の欠陥がある）スタブインターフェイスを返します。

悪口を言わずにできるのか？ ここの掲示板に女性が来ることがあります。

 
mql_coder >> :
EX5ライブラリは、インターフェース（仮想関数を持つクラス）を返すという保護効果があるのでしょう。私との「非協調」使用の場合、インターフェースのスタブ（あまり目立たない計算ミスあり）を返します。

価値があれば割られるし、クリーンなヒューマノイドとのインターフェースは役に立ちません :)

したがって、保護は他の場所と同じで、コードへの物理的なアクセスはできず、さらにトレードレビューで特定のTSに必要な遅延が発生します（株式投資家はリアルタイムに与えられるかもしれません）。


まあ、EAにおけるOOPは、イベントから始まり、有能なサポートや微調整の可能性など、非常に価値のあるものです。もちろん、C#がなぜ良くなかったのか理解できません。明確な名前空間宣言を持つMQL5フレームワークがないことと、非標準＋未熟な言語であることから、当初想定していた以上の努力が皆に必要だからです :(笑)。

 
Avals >> :

もはやOOPを核とするものではない（絶対OOPは事実上使えないが）。最初から抽象的なクラスを作り、継承やポリモーフィズムを使って本当のオブジェクトに到達すべきだったのです。例えば、抽象的なメソッドやプロパティを持つカスタム・インジケータのための抽象的なベース・クラスを作成する場合。グラフィカルなオブジェクト、アカウントでの作業、スケジュールや時系列へのアクセスなど、クラスの階層的なツリーを構築するのがよいでしょう。また、あらかじめ定義された手順や機能については、速度を必要とする初歩的なルーチンのみを残すようにします。そうすれば、どの抽象度からでもプラットフォームの機能を拡張することができ、コードサイズを小さくし、他のプログラマーにとっての読みやすさや理解しやすさを向上させることができるのです。また、MT5ではすでにプロシージャレベルでかなり複雑なものが実装されており（実際、プラットフォーム全体がすぐに使える）、少なくとも作成した内部構造体の記述子へのポインタによるアクセスの可能性を見たことがなく、（ヘルプから判断して）非常に制限されているのが現状です。一般に、OOPの必要性には疑問があり、このような実装では、構造体と動的配置に限定される可能性があります。OOPは、よく整備されたクラスの階層によって、下からサポートされるべきです。

ええ、そういうことです。IMHOのやり方では、あまり意味がないと思われます。そのためにあるんです。それにしても、もしかして他の意見もあるのでは？

 
Whistles'n'Bells、間違いないです。ただ、外部オブジェクトへの対応があれば、それに越したことはないですね。
 
alexjou >> :
Whistles'n'Bells、間違いないです。ただ、外部オブジェクトへの対応があれば、それはそれで素晴らしいことです。

名前空間がなければ、とても実現できない。

 
pisara >> :

名前空間がなければ、適切なサポートを提供することは実際不可能です。

マイクロソフトのこの最新の派手なものはなくても大丈夫です。しかし、少なくともwinndaの話をしている間は、この「インターフェイスライブラリ」のような最新の空想的なものは必要ないでしょう。実際、MTの開発者は墓場までメルコムソフトに不滅の忠誠を誓い、それ以外には目もくれないようで、残念なことです。私の直感では、完全に罪のないMT5さえもWine経由でLinux上で動作させるのは、本当に大変なことだと思うのです。

 
優先順位を明確にする必要がある。WindowsのシェアとLinuxのシェアは？市場アプリケーションにおけるwindsのシェア、linuxのシェアは？などなど。次に、WindowsとLinuxの両方について、導入の経済性を計算する。アフターサービスも忘れてはいけない。結果は、Linuxに有利とは言い難いものでした。そして、これらは単なる言葉ではありません。リソースの流用は、WindowsとLinuxの両方のアプリケーションの品質に影響を与える。資源が分散している中で、メタクオーツが市場に残るかは定かではない。今は、Windows版MT5のリリースが主な優先事項です。このプロジェクトは 市場に出すべきものです。そして、リソースが許す限り、他のOSについても考えてみてください。MT4を3つのOSに同時に対応させること（現時点）でも、大きなリソースが必要です。そして、mt5の開発です。気長に待ちましょう。MQL5でのOOPは大きな前進です。さらに、mt4にはなかった機能がたくさんあります。OOPが要求されるかどうか...。それは、きっと...大量に使うつもりはないのですが...。また、OOPを大量に使うというような課題もありませんでした。少数の一流アプリケーションであっても、大きなシェアを獲得することが可能です。そして、そのようなアプリケーションが存在することは間違いない。
 
優先順位を明確にする必要がある。WindowsのシェアとLinuxのシェアは？市場アプリケーションにおけるwindsのシェア、linuxのシェアは？などなど。次に、WindowsとLinuxの両方について、導入の経済性を計算する。アフターサービスも忘れてはいけない。結果は、Linuxに有利とは言い難いものでした。そして、これらは単なる言葉ではありません。リソースの流用は、WindowsとLinuxの両方のアプリケーションの品質に影響を与える。資源が分散している中で、メタクオーツが市場に残るかは定かではない。今は、Windows版MT5のリリースが主な優先事項です。このプロジェクトは 市場に出すべきものです。そして、リソースが許す限り、他のOSについても考えてみてください。MT4を3つのOSに同時に対応させること（現時点）でも、大きなリソースが必要です。そして、mt5の開発です。気長に待ちましょう。MQL5でのOOPは大きな前進です。さらに、mt4にはなかった機能がたくさんあります。OOPが要求されるかどうか...。それは、きっと...大量に使うつもりはないのですが...。また、OOPを大量に使うというような課題もありませんでした。少数の一流アプリケーションであっても、大きなシェアを獲得することが可能です。そして、そのようなアプリケーションが存在することは間違いない。
123456789
新しいコメント