MQL5におけるOOPに関する質問 - ページ 9

新しいコメント
 
Igor Makanu:

見落としたものはすべて端末で報告され、それを削除する場所も知られている - OnDeint() ...。この議論は、真空中の球形馬の議論になってしまったのでしょうか？)))

いや、馬は乗るべきところに乗らせる。

しかし、私たちが議論しているのは、これまで知られていなかったオブジェクトの創造です。しかも、その特性だけでなく、作成されたオブジェクトの数自体もわからない。

もちろん、あるオブジェクトに対してポインタを作り、このポインタによってそのオブジェクトを操作することも可能です。しかし、ポインタがいくつ必要になるか事前にわからないとしたら、一体どんなバキュームなのだろう。ポインタをリストに格納するというのは、最もシンプルですぐに利用できる方法のひとつに過ぎない。リストからの取り出しが可能です。さて、各オブジェクトは識別子（Type()メソッド）を持つことができ、それによってポインタオブジェクトを識別することができます。オブジェクトを正確に識別することができる（オブジェクトには、その型に加えて、同じ型のオブジェクトと区別するための他のプロパティが付与されることがある）。

一般的には、オブジェクトの分類、保存用のリスト、オブジェクトの操作方法などが必要で、要求に応じて情報を保存したり与えたりするだけでなく、プログラムと相互作用して「生きて成長」し、時折自分自身の行動を変更したり、その行動について報告したりする、より複雑な構造について話しているように感じられるのです。

おそらく私は行き過ぎた議論をしてしまい、2つのフィールドが初期化時に変更されなければならず、オブジェクトのライフタイム中はいかなる形でも変更されてはならないオブジェクトについてだけ述べています。入力変数があるのに、オブジェクトを持つ意味があるのか？

 
物を作った人以外には、物を取り除く義務はない。仮にそうなるケースがあったとしても、信用することはできない。作ったのなら、削除する。
 
Dmitry Fedoseev:
オブジェクトを削除する義務は、それを作成した人以外にはありません。場合によってはそうなるとしても、信用してはいけない。作ったのなら、削除する。

それはそうですね。でも、そういう話ではないんです。そうでしょう？

オブジェクトが絶対に失われず、明確に見つけることができる方法について話しています。

オブジェクトを作成するときは、後できちんと削除できるように、また、オブジェクトのポインタを失ったことによるメモリリークがないように、意識して作成しましょう（関数に渡されたオブジェクトへのポインタが、関数本体で新しく作成したオブジェクトに再代入されている例から、メモリリークが発生していることがわかります）。

そして、あるものが好きな人、別のものが好きな人、人それぞれの好みがあります。しかし、後で削除できるように、それぞれのオブジェクトについて知っておく必要があります。たとえ2つでも2,000と2つでもです。そして、私たち自身がdeleteで削除するか、リストにClear()で削除させるか、ループ内でリストとdeleteで削除するか、他の方法で削除するか - それは関係ないのです。

 
Artyom Trishkin:

一般的には、オブジェクトの分類、保存用のリスト、オブジェクトの操作方法などが必要で、要求に応じて情報を保存したり与えたりするだけでなく、プログラムと相互作用して「生きて進化」し、時折自分自身を変化させ、その行動について報告する、より複雑な構造について話していると感じています。

もしかしたら、私は行き過ぎた議論をしてしまったかもしれません。2つのフィールドが初期化時に変更され、ライフタイム中は一切変更されてはならないオブジェクトについて議論する必要があるのでしょうか？入力変数があるのに、オブジェクトを持つ意味があるのか？

これは、OOPの不思議な概念です。 まず、OOPは便利です。一度書けば、あとはそのオブジェクトの新しいインスタンスを作るだけです。

冒頭に戻って、私の例ですが、よく使うのはhttps://www.mql5.com/ru/forum/160683/page861#comment_11840254 です。

今は時間間隔を1回、次回は2回に限定して取引したいのですが・・・。4...

私の2クリックの例は、このタスクのために修正されています。

int OnInit()
{
   Work1=new CWorkTime(StartHour1,StartMinute1,StopHour1,StopMinute1);
   Work2=new CWorkTime(StartHour2,StartMinute2,StopHour2,StopMinute2);
   Work3=new CWorkTime(StartHour3,StartMinute3,StopHour3,StopMinute3);
   Work4=new CWorkTime(StartHour4,StartMinute4,StopHour4,StopMinute4);
}


でも、カテゴリーで考えると、OOPはすべてをクラスで包むだけのもので、そこに私のスーパークラスという奇跡があり、それが両方できる......。また、クラスが10個の文字列であれば、OOPは必要ありません。なぜ自分を制限し、皆を誤解させるのでしょうか？

私は自分に都合の良いところではOOPを使いますが、議論は明らかに宗教の世界に行っています。）

 
Igor Makanu:

これは、OOPの奇妙な考えです。OOPは、まず第一に便利です-一度書いたら、新しいオブジェクトのインスタンスを作成します。

冒頭に戻って、私の例ですが、よく使うのはhttps://www.mql5.com/ru/forum/160683/page861#comment_11840254 です。

今は時間間隔を1回、次回は2回に限定して取引したいのですが・・・。4...

私の2クリックの例は、このタスクのために修正されています。


でも、カテゴリーで考えると、OOPはすべてをクラスで包むだけのもので、そこに私のスーパークラスという奇跡があり、それが両方できる......。また、クラスが10個の文字列であれば、OOPは必要ありません。なぜ自分を制限し、皆を誤解させるのでしょうか？

私は便利なところではOOPを使うのですが、明らかに宗教の話になっていますね。）

間違いないですねー、私自身はOOPを積極的に使っているので、この宗教に入るようなことはないです。

例えば、もう少し間隔が必要な場合はどうするか。新しいものを作るべきか？何のために？プログラムコードに干渉せず、1つのリストでできることなら。

話が違うような気がするのですが。ユーザビリティの話なんですが、あなたは...。私もユーザビリティの話をしているのですが、使えないコードを表示しているんですね。もちろん大げさなだけかもしれないし、理解できなかったけど...。

 
Artyom Trishkin:

例：もっと間隔が必要な場合はどうするか？新しいWorkNNNを作るべきですか？何が言いたいの？プログラムコードに干渉せず、1つのリストで管理できれば......。

クラスインスタンスのリストや配列を使う必要がある場合は、大した問題ではありませんが、この例では配列を使う方が簡単で、ループを1つだけ作ることができます。

bool DisableTrade=false;
   for(int i=0;i<ArraySize(Work);i++)
     {
      if(Work[i].Disable()) {DisableTrade=true; break}
     }
   if(DisableTrade)
     {
      Comment("Не торговое время!!! Сопровождение открытых ордеров");
     }
   else...

アルチョム・トリシキン

話が違うような気がするのですが。ユーザビリティの話なんですが、あなた ...私も使い勝手の話をしているのですが、表示されているコードが不便なんです。もちろん大げさで、私が理解していなかっただけかもしれませんが...。

仮にユニバーサルコードを書いたとしても、それをさらに修正するのは面倒な作業で、結果的にユニバーサルコードはより多くのリソースを必要とすることになる--一般にこのことは永遠に語られるかもしれないが、かつて私は、ある有名なプログラマーがこう言ったと書いた--「コードはそのタスクを実行しなければならない- それで十分です」。残 りはすべて ...まあ、ふざけたい願望というか...。 作ろう！と言い出す。)))

 
Artyom Trishkin:

///

例：もっと間隔が必要な場合はどうするか？新しいWorkNNNを作るべきですか？何が言いたいの？プログラムコードに干渉せず、1つのリストで管理できるのであれば。

///

その場合、プロパティウィンドウには、数値インターバルパラメータは表示されません。最適化することができなくなります。オプションではありません。

また、インターバルごとに新しいオブジェクトを作成することも最良の選択ではありません。それでも性能は落ちます。もしクラスを作るとしたら、intervalのパラメータを配列に追加するようなものを作るべきでしょう。より速くなります。

 
Dmitry Fedoseev: rmosa.もし、クラスを作るのであれば、インターバルのパラメータを配列に追加するようなものにする必要があります。より高速になります。

1つのクラスや関数に複数のパラメータを追加しても、個々のパラメータを持つ複数のクラスを作成しても、全く違いはありません。

SZZ：大きな関数を長い "馬のテープ "のような形で書くと、CPUキャッシュが必ずしも有効に使われないことをお忘れなく......。テストでしかわからないのですが、特定のPCと特定のコンパイラで......。

 
Dmitry Fedoseev:

そうすると、プロパティウィンドウに数値間隔パラメータが表示されなくなります。そこから最適化することはできないでしょう。オプションではありません。

間隔ごとに新しいオブジェクトを作成するのは、最良の選択肢とは言えません。結局のところ、これはパフォーマンスの低下につながるのです。もしクラスを作るとしたら、intervalのパラメータを配列に追加するようなものを作るべきでしょう。その方が早いでしょう。

同意見です。繰り返しになりますが、すべてはチェックアウトフィールドの設定方法に起因しています。また、入力パラメータからすべての間隔を記憶するオブジェクトにどのように転送するかは、テクニックの問題である。間隔のリストにあるすべてのオブジェクトを再作成することは可能ですが、そのうちの1つだけを変更する場合 - コードを書くときにデータを変更するのが「面倒くさい/面倒じゃない」のは、実用性の問題です。

 
Roman:

new演算子でダイナミックオブジェクトを作成する感覚を説明してください。

オブジェクトを自動生成する場合、クラスオブジェクトはスタックに作成され、実行時間の 点ではダイナミックオブジェクトより高速になります。
オブジェクトを動的に生成する場合、クラスオブジェクトはOSのメモリーマネージャーを介したメモリー内（ヒープ内）で生成されるため、処理が遅くなります。

以下、質問です。
自動生成の方が速いなら、なぜダイナミックオブジェクトを使った方がいいのでしょうか？
メモリ割り当ての明示的な制御？
スタックオーバーフローの可能性を排除する？
そして、不意にモノを失わないこと？
スタックがオーバーフローすると、オブジェクトが自動的に削除されるから？

こんにちは。コンピュータのメモリは、スタックとヒープのどちらのコンテキストで使われても同じ性能になります。動的メモリ管理自体はゴミ収集器の実装に依存します。例えば、Pythonのような参照カウント（より遅いバージョン）、バックグラウンドプロセスで実行グラフのトラバースを行うオブジェクト生成エポックの分析（Net CLR）などがあります。MQLでどのようなバリエーションが使われているかは不明ですが、MQL5のユーザーは直接delete演算子にアクセスできるため、GCの作業自体が大幅に簡略化され、非常に効率的であると推測されます。したがって、newを使用する際のオーバーヘッドに関する懸念は杞憂に過ぎず、自由にダイナミックメモリを使用することができます。

スタックオーバーフロー」については、現代のシステムでこのケースに遭遇するのは、複雑な再帰を使用する場合や再帰アルゴリズムにミスがある場合のみです。最近のプログラムは、常に仮想アドレス空間のOC protected modeで動作し、メモリページをダイナミックにロードするので、スタックがオーバーフローすることはありません:)。

12345678910111213141516...96
新しいコメント