Этот вопрос в основном указывается на C/С++, но я думаю, что другие языки также актуальны. Я не могу понять, почему используется параметр switch/case вместо if/else if. Мне очень нравится использование goto's и приводит к тому же виду беспорядочного кода, в то время как те же результаты могут быть достигнуты с if/else, если более организованным...
結果
3番目のバリエーション(スイッチ)は、2番目のバリエーション(関数ポインタ)よりも着実に遅くなっています。その理由は何でしょうか?
ZS ゆっくりと。3番目のスイッチは、2番目のスイッチよりも高速です。すべて順調です。
つまり、関数へのポインタの不変配列がある場合、それをswitchに置き換えると高速になります。
つまり、関数へのポインタの不変配列がある場合、それをswitchに置き換えると高速になります。
この場合、配列は動的に埋められるので、ポインタの有効性を常にチェックすることになり、論理的です。 もちろん、最適化することも可能ですが......。
しかし、もしMQLが定数ポインタによる配列の初期化を サポートしていれば、おそらく同じになるはずです。
p.s. あなたのコードは全く読めません。もちろん、自分で書いたのだから、マクロが何をするものかは分かっているので、こうした複雑なことを便利に感じるのは分かります。 しかし、外部の読者にとっては、ただのパズルに過ぎないのです。あなた自身、半年後にはここで何をしたのか理解できていないと思います)せめてコメントか何かをしてください.
p.s. あなたのコードは全く読めません。もちろん、自分が書いたものだから、マクロが何をするものかわかっているから、こうした工夫に抵抗がないのはわかります。 しかし、外部の読者にとっては、ただのパズルに過ぎないのです。あなた自身、半年もすれば何をしたのかわからなくなると思います)せめてコメントか何かをしてください.
そうでなければ、あなたは混乱してしまうでしょう。さらに、トランジションの数を試行錯誤していました。マクロがなければ難しかったと思います。追加コメントについて-今後に生かします。
そうでなければ、混乱するところだったでしょう。さらに、トランジションの数を実験してみたんです。マクロがなければ難しかったと思います。追加コメントについて-今後に生かします。
コンパクトなパズルを分解し始めてすぐにこの無駄な活動を放棄するよりも、理解しやすいスプロールを分解する方がはるかに簡単なことがあります。
コンパクトなパズルの解析を始めてすぐに無駄な作業を放棄するよりも、理解できる文章を解きほぐす方がずっと簡単な場合もあるのです。
上記に加えて、テスターで不一致のランが発生する最も一般的な原因の1つは、誤った初期化またはその欠如です。
足りない変数の初期化は簡単ですが、配列は少し複雑です。多くの場合、配列の要素 数が増える状況を見つけることが、問題の場所を示している可能性があります。
このような潜在的な問題を捕捉するために、Expert Advisorの最初に以下の文字列を挿入します。
もし、この状況に陥った場合は、詳細情報をログに書き込み、実行を停止します。
SZZ アプリケーションの例 です。
なるほど、私自身もよく使う方法ですが、初期化についてはどうでしょうか。どうして無効なんだ?
例えば、ArrayResizeとArrayInitializeが 混在している。あるいは、例えば、インジケータが OnInit でバッファの ArrayInitialize を実行し、バッファが初期化されたと誤認している。
例えば、ArrayResizeとArrayInitializeが混在している。
まあ、これは非常に幼稚なエラーですが、それを見つけるためにこれほどの努力をする価値があるのでしょうか?
まあ、幼稚な間違いなんだけどね。 探す労力はあるかな?
どんなエラーでも見つけるのは努力が必要です。特に、コードが大きく、自分のものではない場合。