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

 
Igor Makanu:

はすべて動作しますが、インジケータバッファと なる配列は修飾子 public で記述する必要があります。

はい、もちろんです。

もちろん,クラスメンバへのパブリックアクセスはよくないのですが,一番の問題である配列データへのコピーなしアクセスは解決しています.

ありがとうございます、問題が明確になりました。

 
疑問が解けたなら、助けてくれるのか?プログラミングのマンモスの皆さんには、葦のようなものですが...。
 
Georgiy Merts:

もちろん、クラスメンバへのパブリックアクセスはよくありませんが、一番の問題である配列データへのコピーなしでのアクセスは解決されています。

YouTubeでいろいろな動画を見ていて、ある知的プログラマーのチャンネルに出会ったのですが、「コードはまず、そのタスクを実行しなければならない!」という言葉が印象に残っています。

大きなプロジェクトに携わるわけではないのですね。- なぜこのクラスのメンバが 定義されているのか、コンパイラの助けを借りずにアクセスを制御することができるのか、お分かりでしょうか?;)

 

mt4のビルドを更新しました。


コンパイルと実行エラーで正常に動作していたコード


 
Igor Makanu:

YouTubeでいろいろな動画を見ているうちに、優秀なプログラマーのチャンネルに出会い、「コードは、何よりもまず、そのタスクを果たさなければならない!」という言葉を思い出しました。

大きなプロジェクトに携わるわけではないのですね。- なぜこのクラスのメンバが 定義されているのか、コンパイラの助けを借りずにアクセスを制御することができるのか、お分かりでしょうか?;)

実際には、クラスのメンバへのアクセスはメソッドで実装した方がよく、実行時の再参照を少なくするために、getメソッドをインラインで使用します。
 
Igor Makanu:

YouTubeでいろいろな動画を見ているうちに、優秀なプログラマーのチャンネルに出会い、「コードは、何よりもまず、そのタスクを果たさなければならない!」という言葉を思い出しました。

大きなプロジェクトに携わるわけではないのですね。- なぜこのクラスのメンバが 定義され、コンパイラの助けを借りずにアクセスを制御できるのか、おわかりでしょうか?;)

NO.

まず、コードが透明で理解しやすく、メンテナンスが容易であることが必要です。そして、もしその役割を果たせなかった場合は、すぐに目に見える形で表示されます。

しかし、コードが、非常に微妙で明白でないエラーを引き起こす潜在的に安全でない構造を持つ多くの断片で満たされている場合、「コードがそのタスクを遂行する」ことを確認することはできません。

また、大きなプロジェクトに取り組む際には、まったくなくてはならないもので、多くの企業では、表記や申告、株式として申告できるものとできないものなど、公式のガイドラインがあります。もちろん、一人で作業するときは、クラスメンバーを宣言し、それが何のためにあるのか、どのように使うのかがわかっている状態です。ただし、どんなに複雑なコードでも、たとえ一人のプログラマーが行ったとしても、アーキテクチャを変えてしまう傾向がある。そして、私自身は、何が、どこで、どのように、何のために、ということを思い出せないのです。同時に、詳細なコメントを惜しみなくコードに書き込んでいます。それでも、半年後に他のフラグメントに戻ると、なぜそうなったのか、違うやり方ではダメだったのか、かなり時間をかけて理解します。コメントがなければ、自分のコードをまったく理解できない。

もちろん、Peter Konovの記憶力があれば、アクセス権の共有など気にする必要はなく、すべての変数をグローバルにし、必要なときに必要なものを使うことができるのです。しかし、記憶力は格段に悪く、1週間もすればもう手順の微妙なところを忘れてしまいます。ですから、私はずっと以前に、コードのどの場所にも、私がここで必要とするのとまったく同じだけの変数があり、それ以上はないという原則を確立しました。ベストな方法は、すべてを仮想インターフェイスに変換し、各クラスの責任範囲をできるだけ分割することです(もちろん、有用なコードよりもこれらのラッパーに対処しないような方策は必要です)。

配列へのポインタがないのは、開発者が「プログラマへの配慮」として正当化していることを思い出してください。 クラスについては問題ありませんが。まあ、「クラスを使って書いている人は、すでにポインタを使えるだけのスキルがある。一方、配列は初心者でも使えるし、配列へのポインタを使いたいときに困ってほしくない...」という説明でした。no pointers, that's all」...。

 
Vladimir Simakov:
一般に、クラスのメンバへのアクセスはメソッドで実装するのがよく、実行時の再参照を避けるために、getメソッドとインラインで使用します。

その通りです。 そして、普段から傾倒しているのです。私はパブリッククラスのメンバは ほとんど使わず、インラインメソッドでアクセスします。 インジケータ配列のような特殊な場合のみ、パブリックメソッドを使用する必要があります。

 
Влад:
もし問題が解明されたら、助けてもらえますか?プログラミングのマンモスの皆さんにとっては、蛾のようなものでしょうか...。

あなたの場合、for()ループではなく、while()ループを編成してください。

点滅終了の何らかのサインを確認する。

でも、「周波数が変化する点滅」については、何か違和感が......。その場でエラーは出ません、かなりの頻度で点滅しているはずです。

とはいえ、グラフィカルなオブジェクトを 不可視にするのではなく、作成・削除 するのが賢明かどうかは疑問ですが。 でも、オブジェクトを不可視にすることはできないようなので......。だから、あとは削除するだけです。

 
Georgiy Merts:

もちろん、Peter Konovのようなメモリを持っていれば、アクセス分離を気にする必要はなく、すべての変数をグローバルにして、必要なものを必要なときに使うことができる。

私は決してメモリを鍛えることはせず、グローバル 変数は最後の手段としてのみ使用し、コードは時には冗長にさえ見えますが、コードの断片は別のプロジェクトに移植可能です。

私は普段から長い関数名や変数名を使っているので、前に書いたものを読むことができるんです。

void CGrid::Scenario_01(int ordernumber)//------ Сценарий ReOpenBUY & ReOpenSELL
  {
   int set         = Order[ordernumber].StateOrderNumberSetting;
   double pr       = Order[ordernumber].StateOrderStartPrice;
   double vol      = Order[ordernumber].StateOrderLot;
   double volcoeff = dealssettings[set].volcoeff;
   double profit,openprice;
   Order[ordernumber].GetCloseOrderInfo(profit,openprice);
   double l=CalcLot(dealssettings[set].volratio,vol,volcoeff,profit);
   deal=new Cdeal(set,dealssettings[set].dealtype,l,pr,dealssettings[set].closepips,magic);
   Order.Delete(ordernumber); 
   Order.AddValue(deal);
  }
もう一つの問題は、私はOOPスタイルに固執していないことです。私はすべてをクラスにラップせず、一つのプログラムの中で手続き型とOOP型の両方を同時に使います。既製のブロックからプログラムを形成する方が便利で速く、足りないものはすべてタスクに合わせて既製品を追加または変更します
 
Vladimir Simakov:
で、実行時の再参照を少なくするために、getメソッドにインラインで使用します。
コンパイラはすべてを完璧にインライン化するので、コードをオーバーロードする必要はありません。そして、MQLではこの指定子は全くなく、互換性のためだけに追加されたものです(何のために、このようなマクロを自分で宣言できるようにしたのか分かりませんが)。