野心的なアイデア ! - ページ 2

新しいコメント
 
alsu:
実は、OOPはプログラムコードを減らし、プログラムロジックのデバッグにほとんどの時間を費やすための方法であり、データ表現ではありません。

プログラムロジックとデータ表現とは何がどう関係するんだろーか？これらは一切関係ありません。

プログラムロジックは任意の入力データに対する算術演算であり、データ表現は単なるデータの一形式である。

また、内部データ（関数や変数）を直接アドレス指定するのではなく、オブジェクトへの外部ポインタが登場するため、定義上、OOPではプログラムコードを削減することは不可能である。しかし、ポインタやメモリ参照の計算は非常に遅い処理であるため、それに応じてパフォーマンスが低下する。

 
C-4:

...

3.私は筋金入りのロッカーで、私の戦略はすべてMT4のこの無意味で有害な機能に基づいています。しかし、私は、MT4で表示される相場とMT5で表示される相場は同じではなく、根本的に異なる相場であり、一方では儲かる（MT4）、他方では儲からない（MT5）のだと確信しています。

思い込みか事実か？

C-4:

...

4.OOPは好きでも嫌いでもないです。私はそれを知らないし、非常にシンプルで信じられないほど醜いMQL4がある一方で、人々がOOPを選択する理由が本当に理解できないのです。あまりにシンプルでいい加減なので、「Hello forex！」的なプログラムを書くのは信じられないほど簡単で、自動的に多通貨/多タイムフレーム/多システムのEAを書くのは楽勝ということになる。


シンプルな中にある美しさです。

C-4:

...

5.長年の経験にもかかわらず、いまだに理解できない......。


悪い印象を与えないように、そんな文は書かない。

一般的にあなたの投稿を見ると、私のほうに不満があるように思えます。その詳しい説明をメッセージで送っていただき、相談させてください。


MT5では、いろいろなものを奪われました。奪うということは、本質的に基本的なことなのです。MT5では、機能に目移りしてしまいました。ボタンや写真を使ってチャートを表示することができ、私たちの想像力の扉を開いてくれるのです。FXでは、どんなFXソフトも 数学的でなければならず、分析と計算ができなければならない。MT4とMT5は、数学的な演算が同じなので、計算方法は同じです。取引の可能性はそれぞれですが、個人的にはプログラム言語の面でも取引の面でもMT4には満足しています。

mql5を知らないからではなく、MQL4が好きだから問題を解決しようとしている、MQL4への最後のトリビュートと考えることができます。

私はmql4で問題を解決しようとしているのは、mql5を知らないからではなく、MQL4が好きだからです。このプログラミング言語で、4の落とし穴や制限をすべて回避した解決策はまだ見つかっていないので、これが最後のMQL4トリビュートだと考えています。4でできることなら、なぜもっとお金を出して5を買うのか」と声を大にして言いたいです。

 
HIDDEN:

ここ数年、私は定期的に多通貨対応のストラテジーテスターの導入に頭を悩ませています。

実は、このアイデアについて、フォーラムの皆さんからご意見を伺いたいと思っています。おそらくこのスレッドには、開発で使用される材料、つまり、あなたがアドバイスするものが集められるでしょう。

それは便利かもしれませんね。

この落書きは、多通貨を含む仮想トランザクションのライブラリとして使用することができます。 は、決して獲得しないプロジェクトの 一環として作成され、コメントは豊富で、あなたはコードベースで把握することができます未完成のために投稿されていない。希望のノックの淡い幽霊を直に見て、私は参加することができます。

ファイル:
ygenetica.mq4  58 kb
 
ivandurak:

それは便利かもしれませんね。


調べてみます、ありがとうございました。

このような場合、冷静に判断することが大切です。

 
Andrei01:

OOPは、より多くのコードをあちこちに散りばめて書き、同時にプロセッサに負荷をかけるための、小手先のモスクワの宣伝に過ぎないのです。:)

最終的な性能はほぼ同じで、ソフトウェアやハードウェアのリソースの価格を押し上げる。しかし、もちろん彼らは馬鹿ではないので、OOPでプログラムを書くことはない。:)


頭（食べ物を入れる場所）は大丈夫ですか？

go on, go on, これが構造化プログラミングのプロ（あなたのことです）の意見だと思います。

プログラマーがOOPを使うときに、シンプルさとは何かを理解してもらうために、少し付け加えます。

- 私はターボ・パスカルでプログラムを書いていて、すべて順調だったのですが、どうしても普通のインターフェイスが欲しくて、おっしゃるように始めました。賢い手順をたくさん書いて、入力データを入力するウィンドウ、それから結果を出力するいくつかのウィンドウ、それからグラフィカルなモデルを出力するように、そして保存するテキストボックス、でもその後、マウスでウィンドウを動かすことが判明したのです。そして、今作っているモンスターは、8割がインターフェース用のコードで、残りの2割が計算そのものであり、インターフェースはNorton Commanderに追いつくのがやっとという状況を見て、OOPのお手本として光っているTurbo Visionに 興味を持ちました。それ以来、もし私が3週間以上作業したプロジェクトで、さらに作業しようと思っていて、そのプログラミング言語がOOPを書けるのであれば、私はいつもOOP用にコードを書き換えています - すみません、でもそれは私のアイデアではありません。"time is money" - 真剣なプロジェクトでのOOPは時間の節約になる

 

OOPは、プログラマーが誰も手がけていないような複雑なプロジェクトに必要です。他人のコード（久しぶりの自分のコードも）を理解するのはとても難しいですが、OOPではすべてが統一され、透明性があります。小さなタスクにOOPを適用 するのは非効率的です。

 
Avals:

小さなタスクにOOPを適用するのは非効率的です。

OOPは、おそらく百パーセントのプロジェクトで 効率（スピードではなく）においてFPに劣ります。

Andrei01：

OOPは、より多くのコードを様々な場所に散りばめて書き、同時にプロセッサに負荷をかけるという小手先のPRトリックに過ぎない。:)

そのため、最終的な性能はほとんど変わらないのに、ソフトウェアやハードウェアのリソースの価格が上がってしまうのです。しかし、もちろん彼らは馬鹿ではないので、OOPでプログラムを書くことはない。:)

今月のデタラメ

_____________________________________

OOPのルールと、おそらくこのテーマについては十分です。話題が違う。

 
TheXpert:

OOPは、おそらく100パーセントのプロジェクトで、効率（スピードではなく）の面でFPに劣ります。


その統計はどこから来たのですか？ 効率はどのように見積もったのですか？:)
 
経験上 :) 私だけのものではありません。ちょっと嘘かもしれませんが、純粋なFPはもう過去のものです。
 
TheXpert:
経験上 :) 私だけのものではありません。ちょっと嘘かもしれませんが、純粋なFPは過去のものです。
何のために書くのかによる。大多数のユーザーの取引や要望を汲み取れば、FPで十分だと思います。プラットフォームの機能を拡張したり、Expert Advisorを開発 する環境を整えたい場合は、もちろんOOPがルールとなります。
123456789
新しいコメント