エラー、バグ、質問 - ページ 2724

 
Slava :

FileFlushは、変更したファイルを他の人が読めるようにするために行う必要があります。

問題は、MQL5プログラムがファイルを開く際に、独自のバッファに読み込むことです。そして、ファイルを再び読み込むまで、ファイルに何か変更があったことを知ることはありません。そのファイルを一度閉じてから開くことで、再び読み込むことができます

グローリー まさにそこが問題なんです。上に貼ったリンク先に、再現するためのコードがありますので、ご覧ください。

同じEAから同じファイルを開き、書き込み用に1つのディスクリプタ、読み込み用に2つ目のディスクリプタ、書き込み後にfileflushを使用、読み込みを試すと、正しく動作しない。

もちろん、close/openすれば動作しますが、その場合はFileFlushを使用 する必要はありません。

 
Alain Verleyen:

グローリー まさにこれが問題なんです。上記で公開しているリンク先に、再現するためのコードが記載されていますので、ご覧になってみてください。

同じファイルを同じアドバイザーから開き、書き込み用に1つのディスクリプタ、読み込み用に2番目のディスクリプタ、書き込み後にfileflushを使用、読み込みを試すと、正しく動作しない。

もちろんclose/openすれば動作しますが、その場合はFileFlushを使用 する必要はありません。

おっしゃるような問題はよくわかります。

1番目のEAがファイルを書き込む。そのファイルを閉じないかもしれませんが、その場合はFileFlushを呼び出す必要があります。

2番目のExpert Advisorは、ファイルを読み込みます。その都度ファイルを開き、閉じる必要があります。

2つ目のEAだけファイルを開いて閉じる!?

 
Slava:

まさにその通りです。一度閉じて、再度開く

それとも、ファイルを閉じる前にFileFlushすることでしょうか?

はい、閉じる前に洗浄する必要がありますか?それとも閉じることで録画ファイルの関連性が保証されるのでしょうか。

 
Andrey Barinov :

はい、閉じる前に洗浄する必要がありますか?あるいは、記録されたファイルが最新のものであることを保証するために閉じるのでしょうか。

フラッシングは直後に閉じると意味がない。
 
Slava :

おっしゃるような問題はよくわかります。

1番目のEAがファイルを書き込む。ファイルを閉じないかもしれませんが、その場合はFileFlushを呼び出す必要があります。

2番目のExpert Advisorは、ファイルを読み込みます。その都度ファイルを開いては閉じなければならない。

2つ目のEAだけファイルを開いたり閉じたり!?

回避策であることは理解しています。

しかし、間違いを正したほうがいい、簡単にはできない、でしょうか。

 
Andrey Barinov:

はい、閉じる前に洗浄する必要がありますか?あるいは、記録されたファイルが最新のものであることを保証するために閉じるのでしょうか。

必ずしもそうではありません。閉じる前にFileFlushを呼ば なかった場合、バッファは自動的にリセットされます。

 

MT5 (build 2390) で、クラス構造の 記述に含まれる中括弧が正しくカウントされない不具合を修正しました。

class A{};
class B : public A};  // Ok

class C : public A   

void OnStart()
{
   A a;
}                      // Compile Error: '}' - unexpected end of program        
 
Slava:

ファイルを読み込むExpert Advisorは、このファイルを閉じておく必要があります。

MQL5でのファイル実装の特徴は、ファイルからのデータをできるだけ自分のバッファに保持することです。もし、情報のサイズが大きく、バッファに収まらない場合は、ポインタをファイルの先頭から末尾に移動させるというトリックが有効な場合があります。

そのため、現時点では、ファイルを開いて 内容を確認し、再び閉じる

上に書いたように、私のテストケースではその逆で、インジケータが読み、Expert Advisorが書き込みをします。しかし、私が理解する限り、プログラムの種類は重要ではありません。問題は建築的なことです。

MQL5で指定されたファイルの実装はバグです。ファイルを閉じたり開いたりするのは回避策ですが、共有ファイルを読むにはこうはいかないはずです。

パフォーマンスの最適化に気を配るのは良いことですが、機能に悪影響を及ぼしてはいけません。

PS.読み出し用に開かれているファイルに対するFileFlushコールに応答して、そのバッファを更新します。

 
Vict:

おそらく、μl C++も似たようなもので、構造体はCから入ってきたものだからでしょう。

コンストラクタが必要な場合は、クラスを使用するか、Sharpへようこそ。なぜ、構造物からこの意味合いを奪う必要があるのでしょうか?そうすることで、プログラムの表現力がより豊かになるのです。誰かのコードを読んで、その人がクラスではなく構造体を持っていることを知り、たった一語から多くの情報を得ることができるかもしれないのです。何も得られない、同じ結果を得るためにソースコードを熱心に研究する、それは私が瞬く間に手に入れたものです。私の経験では - この構造の慣習は、まあ、多分、風の虚無的なマージナリズムのいくつかの種類を尊重されています。

しかし、C++では、構造体とクラスは同じものである。だから、「コードの表現力」なんて 理屈は、物事の本質には 影響しないんです。構造体やクラス以外の表現力のある言葉をdefineで定義しても、何も変わらない(C++のことです)

構造体は値型なので、クラスよりもはるかにコンパクトであり、ポリモーフィックでなく、参照もできません。 特に後者は重要です。

そこに悪はない、と思えるのです。標準的な拡張もあります: 初期化されていない unsigned char や std::byte の読み込みは undefinded の動作ではありません。PODにアグリゲート初期化を使用することができます。そして忘れてはならないのは、この初期化はすべて無料ではなく、実際のリソース消費(CPU、メモリ、実行ファイルのサイズ)であるということです。マイコンの場合は重要かもしれませんね。やはり、C/C++はシャープのようなWindowsのフォームファクターだけではありません。

1つの変数を初期化するだけで、命令サイズが30%増加した。

初期化が無料であるとは誰も言っていませんが、いずれにせよ初期化は必要なわけで、初期化ありとなしでの計測の意味がよくわかりません。

もうひとつは、コンパイラが変数を再初期化しないことです。

int a= 0;  // Эту инициализацию компилятор вырежет
//...
a= 10;

だから、変数の事前初期 化を恐れるという偏執狂は馬鹿げている。 これは2020年、特にPOD-structuresについて言えば、その初期化はコンパイラによって最適化されるに違いないのだ。

初期化しないことは、未初期化の変数の読み取りを禁止するコンパイラ制御が100%である場合にのみ許容されます。

 
Alexey Navoykov:

C++では、構造体とクラスは同じものである。だから、「コードの表現力」についての議論は、物事の本質には 影響しない。構造体やクラス以外の表現言語をdefineで定義しても変わらない(C++の ことです)。

なんて頑固な人なんだ )))、それはあなたも同じことで、何もdefineで定義しなくても、structという言葉がすでにあるのです。無視してもいいが、その場合、まともなコーダーは、関数を詰め込んだ構造を見て、クソコーダーと見るだろうから、驚かないように。おそらく、クロスの黎明期に構造とクラスを同一視したのが間違いで、C言語のように構造を残しておくべきだったのでしょう。

構造体は値型なので、クラスよりもはるかにコンパクトで、多相型でなく、参照もできません。 特に最後の部分が重要です。

シャープはクリーンなフィールドに現れたと思いますか?C言語に根ざした、余計な糖分を含まないダムコンテナのような構造です。

もうひとつは、コンパイラが変数を再初期化しないことです。

int a= 0;  // Эту инициализацию компилятор вырежет
//...
a= 10;

だから、変数の事前初期 化を恐れるという偏執狂は馬鹿げている。 これは2020年、特にPOD構造体について言えば、その初期化はコンパイラによって最適化されるに違いないのだ。

なぜ、そう言い切れるのですか?他の翻訳ユニット/他のモジュール/サイクル/コンパイラの調子が悪い/...から関数を呼び出す。.オプティマイザーの能力を過信しないこと。これは、コンパイラに義務付けられているCopy elisionの最適化ではありません。もし、オプティマイザーが賢くなり、コストがかからなくなったら、次のC標準に「デフォルトの初期化ではオブジェクトを未定義の状態にしない」と書かれるでしょう。