OOPと手続き型プログラミングの比較 - ページ 24

[Alexandr Andreev]

Dmitry Fedoseev:

1.基準があるんです。主な基準は動作の速さです。

コードの視認性は間違った判断基準です。

みんな緊急でアサンブラに切り替えろ......でも早く......。たしかに速いのは、プロジェクト 全体がきちんとまとまっているか、個々の機能の速さだ

[Konstantin Erin]

Alexandr Andreev:

みんな急いでアサンブラーに移動して......でも早く......。しかし、速いのは、プロジェクト全体の適切な組織化、あるいは個々の機能の速さである。

アセンブラ＋DLL

[Dmitry Fedoseev]

Alexandr Andreev:

みんな急いでアサンブラーに移動して......でも早く......。本当に速いのは、プロジェクト全体の適切な組織化か、個々の機能の速さだ

いいえ、***を通してコーディングを続けてください。

[Dmitry Fedoseev]

George Merts:

そうですね、私は反対です。

コードの明確さは非常に重要なことで、明確なコードは保守や修正が非常に容易だからです。

その通りです。私は裸の関数を書き、それを実際に「難読化」して、見えないように、理解できないようにしました。これは強引な決断だった。今回は、クラス全体を透明化することの方が重要でした。私は、ある極めて些細な機能のわかりやすさを犠牲にしています。もちろん、この関数の本体を.mq5ファイルに書いてもよかったのですが、インターフェースは2つのファイルに分けるべきでなく、ヘッダーファイル.mqhに完全に記述すべきと考えています。

スピードも留意すべき点ですが、「何が何でもスピードアップ」という努力はしない方がいいと思います。合理的な充足感が必要です。

おそらく、あなたにも同じポイント3が あると思います。

[Dmitiry Ananiev]

私は長い間、プログラミングをしてきました。MT3のリリース以降。

それ以来、私はmql4で手続き的なスタイルで書くことがより快適に感じられるようになりました。1001ラインにはEAを搭載していない。しかも、ライブラリに格納されているのは一部の機能だけです。

そして、MQL5では標準ライブラリを使って います。便利なものです。

しかし、重い関数をどんどん呼び出さないように、パフォーマンスの最適化を行う必要があります。最近、あるEAをMql4からMQL5へ改造しています。ここで紹介されているライブラリを使ってみましたが、全ての機能を理解するのに半日かかり、動作はしましたが、最適化が非常に遅かったです。インジケーターを2本に減らしたところ、すべてが飛ぶようになりました。

結論は簡単です。誰もがどんなスタイルでも書くことができる。MQLは、手続き型プログラミングで数ミリ秒を稼ぐために、コードの最適化を必要とするような言語ではありません。ロジカルなタスクがより重要です。実装の仕方によって、速度には実質的に影響がない。

[Dmitry Fedoseev]

Dmitiry Ananiev:

...

結論は簡単です。誰もがどんなスタイルでも書くことができる。MQLは、手続き型プログラミングを使うことで数ミリ秒を稼ぐことができるように、コードの最適化を必要とする言語では ありません。ロジカルなタスクがより重要です。実装の仕方によって、速度には実質的に影響がない。

だから、高性能を実現するのは手続き型プログラミングだと、やんわりと流してしまうのです。3日前から、余計なブレーキをかけずにOOPだけで解決できる問題を紹介しています。

OOPでは、変数のセットを他のコードから選別することができるため、クラス内部で計算を行う際にメソッドにパラメータを 渡す必要がなくなり、スピードアップに大きく貢献する。手続き型でやっても、膨大な数のグローバル変数を作らなければならず、結果的にコードの可読性がどうしようもなく低くなってしまうのです。

[Dmitiry Ananiev]

Dmitry Fedoseev:

高性能を実現するのは手続き型プログラミングであることを、やさしく教えてくれたのです。この3日間、私はここで、不必要なブレーキをかけずにOOPだけで解決できる問題を示してきました。

OOPでは、変数のセットを他のコードから選別することができるため、クラス内部で計算を行う際にメソッドにパラメータを 渡す必要がなくなり、スピードアップに大きく貢献することができるのです。手続き型でやっても、膨大な数のグローバル変数を作らなければならず、結果的にコードの可読性はどうしようもなく低くなってしまうのです。

Expert Advisors では、コードはティックごとに開始されるため、手続き型の利得はごくわずかです。そして、ティックとティックの間には数百、数十ミリ秒の間隔があることもある。インジケータを気にしたことはありません。インジケーターの実益は見いだせなかった。
大きなプロジェクトはOOPで書いた方が便利だと思います。私自身は、何かを保存するのであれば、構造体を使う方が好きです。
この場合、データへのアクセスがより明確に配置され、プルダウンメニューも非常に使いやすくなっています。構造体を配列に置き換えると、しばしば混乱が生じ、配列の数が増えてしまう。

前回の記事では、特に重い関数を呼び出すことに重点を置いていました。例えば、毎回の刻みで呼び出す必要のないループのようなものです。しかも、新しいバーのたびに行う必要はありません。
そこで、本当の意味での性能向上が図れるのです。

[Nikolai Semko]

ショベルカー対ショベル というのは、面白い議論ですね。

木を植えるならシャベルの方がいいんだろうけど。でも、穴を掘るならバックホウの方がいいかもしれませんね。

[削除済み]

Nikolai Semko:

ショベルカー対ショベル というのは、面白い議論ですね。

木を植えるならシャベルの方がいいんでしょうね。でも、穴を掘るならバックホウの方がいいかもしれませんね。

シャベルしか使いこなせない人もシャベルを使う

[Реter Konow]

Nikolai Semko:

ええ、ショベルカーとシャベルという のは面白い議論ですね。

木を植えるならシャベルの方がいいんでしょうね。でも、穴を掘るならバックホウの方がいいかもしれませんね。

なぜ、地元の園芸家がショベルカーになりきって、木のために溝を作るようになったのかは不明である）。