boolCalendarValueHistory(
MqlCalendarValue& values[], // массив для получения описаний значений datetime datetime_from, // левая граница диапазона времени datetime datetime_to=0// правая граница диапазона времени conststring country_code=NULL, // кодовое имя страны по ISO 3166-1 alpha-2 conststring currency=NULL// кодовое наименование валюты страны
);
ハイライトされた文字列は3つのユースケースです。同時に、時間軸も変化します。そして、values[]配列は、ある方法で処理されます。イベント ID は、このイベントの説明を取得するために使用される。その重要性、時間、その他の属性。
よくわからないものにクラスを使っているのなら、それはOOPではありません。
そうそう、こういうギミックの必要性を理解するまでは、使わない方がいいと忠告しておきます。
このようなやり方では、理解は得られない。
間違った使い方をしていると、理解は得られないと思います。
イゴール、皇帝がフェドート・ストレルツィに与えた 任務を覚えているか?
そして、二人の若者の返事はどうだったのだろうか。
ルールや最終的な結果が分からないのに、どうやって再現しようというのか......。
まあ、そんなものでしょう。ここでは、国によってニュースの時間や量が違うということを真似してみました。
が、PLOに包む必要があるかどうかは未知数です。
;)
は、どのように呼び出され、どのような結果になったかのログです。
2019.09.08 16:00:35.031 tst (EURUSD,H1) NewsRU::NewsRU
2019.09.08 16:00:35.032 tst (EURUSD,H1) NewsEN::NewsEN
2019.09.08 16:00:35.032 tst (EURUSD,H1) NewsFake::NewsFake
2019.09.08 16:00:35.032 tst (EURUSD,H1) Error, not this type FR.
2019.09.08 16:00:35.032 tst (EURUSD,H1) News #1 in 1970.01.01 00:01:51
2019.09.08 16:00:35.032 tst (EURUSD,H1) News #2 in 1970.01.01 00:03:42
2019.09.08 16:00:35.032 tst (EURUSD,H1) News #3 in 1970.01.01 00:05:33
2019.09.08 16:00:35.032 tst (EURUSD,H1) News #1 in 1970.01.01 00:07:24
2019.09.08 16:00:35.032 tst (EURUSD,H1) News #2 in 1970.01.01 00:09:15
間違った使い方をしていると、理解は得られないと思います。
少なくとも「ここには魚がいない」という理解は得られるだろう))。
このような話は、地元の人たちから何度も聞かされてきた。
しかも、それは理解不足からくるものです。
そして、魚がいる!?
ということで、国によってニュースの時間や数が違うというシミュレーションをしてみました。
が、OOPに包む必要があるかどうかはまだわからない。
;)
以下は、すべてがどのように呼び出され、最終的にどうなったかのログです。
いや、イゴール。これは、そのようなアプローチではありません。
ハイライトされた文字列は3つのユースケースです。同時に、時間軸も変化します。そして、values[]配列は、ある方法で処理されます。イベント ID は、このイベントの説明を取得するために使用される。その重要性、時間、その他の属性。
このような話は、地元の人たちから何度も聞かされてきた。
しかも、それは理解不足からくるものです。
そして、魚がいる!?
読んだことがあります。魚はいるが、わからないところはない。mql5にはどんなプロジェクトがあれば、魚が釣れるのでしょうか?mql5で、OOPの必要性が感じられるようなプロジェクトを1つくらいは作ってほしいです。
おそらく、OOPは必要ないのでしょう。原理的には、すべて構造化されたスタイルで行うことができます。しかし、個人的には、危険なほど大きくなり始めたグローバル 変数のセットの代わりに構造体を使おうと思ったのが最初の衝動でした。すでに構造体からクラスに移行していたのですが、その構造体のデータを処理する関数をそのまま構造体に統合するのが理にかなっていると考え、クラスを作成することにしました。これは必然的なことではなく、単にデータを並べて作業しているだけです。
オブジェクトが作成さ れ、 その役目を終えたらすぐに「殺す」必要はありません。
作成されたオブジェクトは、MQLプログラム終了後にOnDeinit関数で "kill "することができます。
プログラム実行中は、すべてのオブジェクトはメモリ上に保持され、アクセスすることができる。
オブジェクトがタスクを実行したのなら、なぜそれをメモリに保持するのか?
メモリーリークは発生しないのですか?
いや、イゴール。ここでは、そのようなアプローチではありません。
ハイライトされた線は、3つのユースケースです。この場合、時間幅が変化します。そして、values[]配列は、ある方法で処理されます。イベント ID は、このイベントの説明を取得するために使用される。その重要性、時間、その他の属性。
アプローチは重要ではありません
OOPを理解したいなら、私の意見(すでに書きました) - 便利ですが、OOPは単なるパラダイム、まあ、いくつかのOOPの概念を組み合わせた書き方です - Wiki...
だから、その逆で、課題をデータ化し、そのデータを処理する方法を考えなければならない...。
1.データはどこに保存されるのですか?- こうぞうたいがい
2.どのようにデータを処理するのですか?- ほとんどの場合、機能の集合体である。
3.データの初期化はどのように行うのですか?- おそらくは構造体の配列で、この配列をゼロにしてからデータで埋める必要があります。
4.以前に書いたコードの柔軟性をどのように確保するのか - リファクタリング?
今、OOPを使えば。
1. クラスのフィールドで、もしかしたらこのフィールドは構造体になるかもしれないが、あるいはデータを保存して継承を行うベースクラスをまったく書かないかもしれないorこのクラスは今議論中のクラスのフィールドになるかもしれない
2.1.メソッドの集合になる。 ベースクラスを書けば、簡単なデータ操作を行うためのメソッドをベースクラス内に作るかもしれないし、ベースクラスを継承すれば、そのクラス内でもそのメソッドが利用できるようになる。
2.2.ベースクラスを継承した後に、1つだけメソッドを変更したい場合、ベースクラスの書き換えは必要ない!ということです。- ベースクラスのメソッドと同じ名前のメソッド(関数)を書けば、継承されるのです!
3. コンストラクタを書かないと、暗黙のうちに呼び出されてしまうので、継承したクラスや自分のフィールドのクラスは、必ずコンストラクタが呼び出されることを念頭に置いています。
4.OOPを使うと、以前に作ったコードの断片を書き直す必要がなく、継承することができる。コンパイラは、ほとんどの場合、プログラマの後始末をします。
まあ、これはOOPに関する私のかなり素人考えですが、一般的に、それは便利で、すべてを効率的に動作させるために、OOP、プログラマではなく、コンパイラの開発者を使用するときの主な仕事は、フィールド/メソッドは、プログラマがミスをした、よく、彼に警告するコンパイルのファイルに含めないように使用されていません)))))。