PLOについての興味深い見解 - ページ 10

新しいコメント
 
Vitaly Muzichenko:

このデザインは、読みやすさとごちゃごちゃ感という点で全く好きではありません。

そうですね)))

正当化できるのはデバッグだけです)

 
Vitaly Muzichenko:

このデザインは、読みやすさとごちゃごちゃ感という点で全く好きではありません。

というのが、もともとの疑問 でした。

最後の例は、@fxsaberの「実行時に100%異なるコードが存在する」という発言です。私は数ページ前にデバッガから逆アセンブラを投稿しましたが、コードは90%同じです。

問題なく読み込めるシンプルな構造を返せないということではなく

 
Igor Makanu:

開発者の方がどこかに書いておられましたが、ここにも同じような情報があります。

はこれを見つけただけです。

switch は、ジャンプテーブルを使用した安全なゴトです。つまり、switchの整数キーを使って'case'アドレスが計算されるのである。このため、switchは辞書のような高度なコレクションはもちろん、if-elseと比べても非常に効率的である。

 
fxsaber:

これでは、「コンパイラが最適にブラッシュアップしてくれるだろう」と期待して、どんな品質のコードでも書いてしまう弊害があるのでは？

ある書き方では、コンパイラが正しいことをするのが確実だとわかっている。他のスタイルでは、コンパイラがより賢いと信じるしかありません。

クロスプラットフォーム、異なるコンパイラなどを考えると、コードで何をしているのかを意識して選びます。

正確に何をするかは、コンパイラーだけが知っている。今日のコンパイラは驚異的なユーティリティを備えている。一般的なコーダーに適応し、その人が何を必要としているのか、すでによく分かっているのです。コンパイラができることは、短い関数で シンプルでわかりやすいコードを書くことです。コンパイラは、多数の関数ノードからなるソースコードグラフを解析して、結果のプログラムを構築する方が簡単で効率的である。これは、必要な機能が適切な場所にインライン化されるため、パフォーマンスに良い影響しか及ぼさない。

 
Vasiliy Sokolov:

switch は、ジャンプテーブルを使用した安全なゴトです。つまり、switchの整数キーから'case'アドレスが計算されるのである。このため、switchは辞書のような高度なコレクションはもちろん、if-elseと比べても非常に効率的である。

クール！これは有用な情報です。

おつかれさま

 

少人数制の授業を書くことを推奨する人は多い。同じエーケルでも、「明確に定義された一つの目的のためにクラスを作る」。

今、あるEAを作っているのですが、例として少し簡略化して書きますね。パラメータに「Reach max stoploss」があります。SLを取得したらカウンターをゼロまで戻してEAの動作を停止させ、TPを取得したら初期値にリセットしてパネルに値を表示させるようにすること。

このカウンターのために、別のクラスを作りました。入力パラメータ設定時のOnInitからと、注文終了後のパネル入力欄からと、複数の箇所から変化することが判明しました（slとtpは異なる値で変化します）。また、OnTick()からメイン関数が呼び出され、EAを停止さ せるためのストップロスの最大数を記録しています。

授業はとてもシンプルなようです。しかし、この小さなクラスは、パネル内にある他のオブジェクト（入力ボックス、ボタン）にも影響を与えることが判明しました。他の機能の動作に影響を与える。そして、そのような小さなクラスが何十個もあると、どの関数がオブジェクトを変更するのか、あるオブジェクトのどのメソッドが他のオブジェクトの状態を変更できるのかを追跡するのは、すでに困難になっているのです。

オブジェクト同士の相互作用をどのように整理すれば混乱を減らせるか知りたいのですが、このテーマに関するコード例、図解、良い解説の記事や書籍はありますか？うまく設計されたアーキテクチャの書き方を学ぶのに役立ったものを教えてください。

 
これはOOPの問題ではなく、EAを作成する一般的なアプローチの問題である。歴史によるストップロスの数を数えるべき。一般に、男の頭というのはこういうもので、万能の解決策はない。
 
Vitaly Muzichenko:

このデザインは、読みやすさとごちゃごちゃ感という点で全く好きではありません。

味と色...。フェルトペンはすべて異なる。

小さな怪物」とは対照的な存在だった。

トレーディング、自動売買システム、トレーディング戦略のテストに関するフォーラム

OOPに関する興味深い意見

fxsaber, 2021.01.31 01:09

小さな怪物。

  static bool VirtualOrderSelect( const TICKET_TYPE Index, const int Select, const int Pool = MODE_TRADES )
  {
    return(VIRTUAL::SelectOrders ? VIRTUAL::SelectOrders.OrderSelect(Index, Select, Pool) :
           #ifdef  VIRTUAL_SNAPSHOT_REFRESHTIME
             VIRTUAL::SnapshotPtr ?
             #ifdef __MQL5__ // Выбор по тикету в MT5 - разнообразный набор вариантов.
               (Select == SELECT_BY_TICKET) ? ::OrderSelect(Index, Select, Pool) && VIRTUAL::SnapshotPtr.CopyOrder()
                                            :
             #endif // #ifdef __MQL5__
                                              ((((Index == INT_MIN) || (Index == INT_MAX)) && (Pool == MODE_TRADES) &&
                                               ::OrderSelect(Index, Select, Pool) &&
                                             #ifdef  VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder(true))
                                             #else // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY
                                               VIRTUAL::SnapshotPtr.CopyOrder())
                                             #endif // #ifdef VIRTUAL_SNAPSHOT_WITHOUT_HISTORY #else
                                               || VIRTUAL::SnapshotPtr.OrderSelect(Index, Select, Pool))
                                  :
           #endif // #ifdef VIRTUAL_SNAPSHOT_REFRESHTIME
           #ifdef __MQL5__
             #ifdef __MT4ORDERS__
               ::OrderSelect(Index, Select, Pool)
             #else // __MT4ORDERS__
               false
             #endif // __MT4ORDERS__
           #else // __MQL5__
             ::OrderSelect(Index, Select, Pool)
           #endif // __MQL5__
           );
  }

論理的な操作により、マクロで設定を使い分ける際にも、簡潔に書くことができます。でも、もちろんホラーです。


 
Andrey Khatimlianskii:

味と色...。フェルトペンはすべて異なる。

そんなことはありません。色が違うだけで、味はどれも同じです(^^))))

 
Vitaly Muzichenko:

このデザインは、読みやすさとごちゃごちゃ感という点で全く好きではありません。

なぜ？

それどころか、2つの「if」を使えば、「or」演算子よりもずっと簡単です。

複雑な条件の結果を論理的な「または」（「および」と混同しやすい）を使って把握し、両方の戻り値のオプションを追跡するよりも、まず一つの条件をチェックして、それが真なら関数を離れ、次に別の条件をチェックして、それも真なら離れる方が簡単だ。

このようなコードの正当性はデバッグにある」と書いてあるのは、かなり面白いです。なぜなら、このようなコードはずっと理解しやすいということだからです（そうでなければ、なぜデバッグにあるのでしょうか？）

「神格化」については、fxsaber氏の表現がありますが、彼自身は「このコードは繰り返しテストされており、動作する」と述べるだけで、その仕組みについては言及しませんでした。それは、あってはならないことだと私は思います。

ENUM_ORDER_TYPE_FILLING CSymbolInfo::GetTypeFilling(string strSymbol,ENUM_ORDER_TYPE_FILLING otfFilingType)
{
   const ENUM_SYMBOL_TRADE_EXECUTION steExeMode = (ENUM_SYMBOL_TRADE_EXECUTION)::SymbolInfoInteger(strSymbol, SYMBOL_TRADE_EXEMODE);
   const int iFillingMode = (int)::SymbolInfoInteger(strSymbol, SYMBOL_FILLING_MODE);

   return((iFillingMode == 0 || (otfFilingType >= ORDER_FILLING_RETURN) || ((iFillingMode & (otfFilingType + 1)) != otfFilingType + 1)) ?
         (((steExeMode == SYMBOL_TRADE_EXECUTION_EXCHANGE) || (steExeMode == SYMBOL_TRADE_EXECUTION_INSTANT)) ?
           ORDER_FILLING_RETURN : ((iFillingMode == SYMBOL_FILLING_IOC) ? ORDER_FILLING_IOC : ORDER_FILLING_FOK)) :
          otfFilingType);
};

このコードは、otfFilingType命令が実行 可能かどうかをチェックし、strSymbolで利用可能な場合はそれを返し、そうでない場合は正しい結果を返します。


仕組みがまったくわからない。そして、fxsaberの権限にのみ依存する。

どなたか解説していただけませんか？

1...345678910111213
新しいコメント