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

新しいコメント
 

ヘルプにはこう書かれています。

市場別」及び「取引所別」の執行モードでは、すべての注文タイプで 常に 「戻り売り」が許可されます。他のタイプの許容は、SYMBOL_FILLING_FOK および SYMBOL_FILLING_IOC プロパティを用いて確認する。

しかし、いつもそうとは限りません。そのため、Robo口座では「Return」が機能せず、Pro口座でもECN口座でも機能しません。

 
Andrey Dik:

ヘルプにはこう書かれています。

市場別」及び「取引所別」の執行モードでは、すべての注文タイプで 常に 「戻り売り」が許可されます。他のタイプの許容は、SYMBOL_FILLING_FOK および SYMBOL_FILLING_IOC プロパティを用いて確認する。

しかし、いつもそうとは限りません。そのため、Robo口座では「リターン」が機能せず、Pro口座でもECN口座でも機能しません。

ロボットと出会ってしまった

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

バグ、バグ、質問

fxsaber さん 2016.10.20 08:24

全取引サーバーのSB
//+------------------------------------------------------------------+
//| Get the property value "ORDER_TYPE_FILLING"                      |
//+------------------------------------------------------------------+
ENUM_ORDER_TYPE_FILLING COrderInfo::TypeFilling(void) const
  {
   return((ENUM_ORDER_TYPE_FILLING)OrderGetInteger(ORDER_TYPE_FILLING));
  }

テスターの ALWAYS はENUM_ORDER_TYPE_FILLING::ORDER_FILLING_RETURN を返します。

そのため、OrderModify で COrderInfo::TypeFilling() を使ってフィリングを設定すると、同じ RoboForexEU-MetaTrader 5 で[Unsupported filling mode] という論理エラーが発生するのです。しかし、MetaQuotes-Demoではこのエラーは発生しません。開発者のサーバーの設定が間違っているのでしょうか？



 
Andrey Dik:

ヘルプにはこう書かれています。

市場別」及び「取引所別」の執行モードでは、すべての注文タイプで 常に 「戻り売り」が許可されます。他のタイプの許容は、SYMBOL_FILLING_FOK および SYMBOL_FILLING_IOC プロパティを用いて確認する。

しかし、いつもそうとは限りません。例えば、「Return」はRobo口座でも、Pro口座でも、ECN口座でも機能しません。

リターン」の設定が全てのトレードサーバーのデフォルトになっているのではないかという疑念があります（少なくともFxProはそう回答しています。

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

サーバーの充填モード

カルプトフ ウラジミール, 2016.10.14 19:18

充填モード "Return"

戻る

IDなし

このモードは、成行（買い・売り）、指値、逆指値注文で、「成行執行」モードと「取引所執行」モードでのみ使用されます。部分約定が成立した場合、残数量のある成行注文や指値注文は削除されず、有効なままとなります。

以下は、「返品」 モードに関する証券会社からの回答です。

MT5の専門家がMetaquotesに確認したところ、リターンはデフォルトで使用され、充填時に何も選択しない場合に適用されるとのことです。

)

つまり、ある種のスタブなのだ。
 
Karputov Vladimir:

フィル設定の「リターン」が全取引サーバーのデフォルトになっている疑いがあります（少なくともFxProはそのように回答しています）。

つまり、ある種のスタブなのだ。

会社によっては（特にMT5は最近発売されました）、充填の種類を明確に指定する必要があり、指定しない場合はエラーになります。

ロボでは、"Return "チェックでサーバーがtrueを返しますが、実はこのようなフィルは機能しないのです。要するに、このフィルで総崩れなんです。

 
このトピックに関係のないコメントは、「OBJ_CHART の CHART_SHOW_OHLC 」に移動しました。
 
明らかに遅いんです。
class A
{
public:
  virtual int f()
  {
    Print(__FUNCSIG__);
    
    return(0);
  }
};

class B : public A
{
public:
  virtual int f()
  {
    Print(__FUNCSIG__);
    
    return(0);
  }
};

void OnStart()
{
//  A* b = new B;
  B* b = new B;
  
  ((A*)b).f();

  delete b;
}
子孫のvirtualがオーバーライドされると、ベースのvirtualに到達できない、ということでよろしいでしょうか？すなわち、bからA::fを呼び出す方法はない。
 
fxsaber:
子孫のvirtualがオーバーライドされると、ベースのvirtualに到達できなくなるという理解で合っていますか？すなわち、bからA::fを呼び出す方法はない。

ほとんど。C++の場合、以下のような入力が可能です。

B* b = new B;
b.A::f();

でも、ここではそれができないんです。したがって、唯一かつ排他的に松葉杖によって。

class B : public A
{
public:
  virtual int f()
  {
    Print(__FUNCSIG__);
    
    return(0);
  }
  
  int f1()
  {
    return A::f();
  }
};
 
Комбинатор:

ほとんど。C++の場合、以下のような入力が可能です。

B* b = new B;
b.A::f();

では、なぜC++で動くのかが理解できない。結局のところ、仮想メソッドテーブルでオーバーライドされたvirtualは、完全にオーバーライドされるべきなのです。そして、ベースとなるものの痕跡はないはずです。

でも、ここでは無理なんです。だからこそ、松葉づえでしかないのです。

class B : public A
{
public:
  virtual int f()
  {
    Print(__FUNCSIG__);
    
    return(0);
  }
  
  int f1()
  {
    return A::f();
  }
};
そうすると、A* b = new B; は動作しません。
 
fxsaber:

やはり、バーチャルメソッド表のオーバーライドされたvirtualは、完全にオーバーライドされるべきです。そして、ベースメソッドの痕跡はないはずです。

型が明示的に指定されている場合は、仮想関数 テーブルを使用せずに直接メソッドが呼び出されます。

こうすることで、純粋な仮想関数であっても、ボディを持てば呼び出すことができる。

fxsaber:
 Then A* b = new B; はうまくいきません。

この場合、別の手段が必要になります。ベースクラスの関数内部を非仮想メソッドに移動し、仮想メソッドの内部でそれを呼び出すのです。そうすれば、ベースクラスや継承元から非仮想的なメソッドを明示的に呼び出すことができる。

 
Комбинатор:

型が明示的に指定されている場合は、仮想関数 テーブルを使用せずに直接メソッドが呼び出されます。

純粋な仮想関数でも、ボディを持てばこの方法で呼び出すことができます。

この場合は、関数内部を基底クラスの非仮想メソッドに移動し、仮想メソッド内部で呼び出すという別の手段が必要になります。そして、ベースとディセンダントの両方から非仮想的なメソッドを明示的に呼び出すことができます。

了解です、ありがとうございます
1...173517361737173817391740174117421743174417451746174717481749...3185
新しいコメント