"ダミー "からの質問 - ページ 14

新しいコメント
 

ここでもう一つ、考えることがあります。やってみて ください。// 結果を報告する。;)

struct s_char8
  {
   char c[8];
  };
struct s_long
  {
   long l;
  };
void OnStart()
  {
    Print("//------ ");
    
    s_long L;
    L.l = 2387159478511726799;

    s_char8 Ch = L;

    string S = CharArrayToString(Ch.c, 0);
    
    Print(S);
   }
 
MetaDriver:

正直困惑してるんだよ、お前ら。 同じ土俵でふざけんなよ。まったくもってフラット。

この "真面目な "会話に謝罪と口を挟みたかっただけなんです。しかし、タバコを買いに行っている間に、やられてしまった。

それに、私たちは "ダミー "ではないでしょう？そして、この「ブーブーブー」は、まさに「ブーブーブー」の連発だった。

CExpertクラスでは、ulongに修正します。

 
Renat:

あなたは間違っています。

はい、タイプ変換のことを忘れていました。

 
uncleVic:

しかも、「ダミー」じゃないんですね。

私はいろいろな面でダサイです。だから、longを返すことを意図した関数がULONG_MAX-1を 返すということが理解できないのです。整数型の表面的な扱いの落とし穴は、ほとんどHandbook自体に書かれている。sergeevは、質問の 理由である「秩序制御」を正しく理解しています。request.magicにulongを指定すると、HistoryDealGetInteger()、PositionGetInteger()、OrderGetInteger()関数もulong型を返すと予想されます。明示的-暗黙的な型変換を行わない。

しかし、彼の 例で、long<->ulong型の変換では（double->intなどと違って）値が失われないことを説明すれば、それ以上の思考回路は明らかになるはずだ。

ビックおじさん

そして、そんな「ブーブーブー」が、何もない空間に生まれた。

実は「ダミーの質問」スレッドは、諭すのではなく、説明を受けるために選ばれたのです。

 
Yedelkin:

私はいろいろとダミーなんです。だから、longを返すはずの関数がULONG_MAX-1を 返すというのは理解できない。整数型の表面的な扱いの落とし穴は、ほとんどHandbook自体に書かれている。sergeevは、質問の 理由である「秩序制御」を正しく理解しています。request.magicをulong型にすると、HistoryDealGetInteger()、PositionGetInteger()、OrderGetInteger()関数もulong型を返すと予想します。明示的-暗黙的な型変換を行わない。

しかし、彼の 例で、long<->ulong型の変換は（例えばdouble->intと違って）値の消失を引き起こさないことを説明すれば、さらなる思考回路が明らかになる。

実は、「ダミーの質問」スレッドは、叱責ではなく、解明を目的に選ばれたものなのです。

気分を害した？すみません、どうしようもありませんでした。
 
uncleVic:
気を悪くされたのでしょうか？すみません、どうしようもなくて。
そんなことないですよ、ネットバトルは経験済みです。ただ、私はいつも、いわば建設的な方向に議論を誘導するように心がけています。
 
sergeev:

実際には64ビットではなく、63ビット（つまり不完全な8バイト）しかないのです。8バイトは、長い 範囲をすべて使用した場合です。

しかし、残念ながら...。

一方、MqlTradeRequest 構造体には、魔法のulongが渡さ れる。正の値しか設定できないことを意味する。

一方、PositionGetInteger/OrderGetInteger関数は long 型を返します 。ulongレンジの半分がカットされるということです。

全部で64ビットではなく、63ビットになりました。実は、オーダーチェックの原則に大きな不都合が あるかというと、そうでもないのです。

MT4と同じシステムで、サインでマジックを許可する方がよっぽど快適だと思うのですが。多くのトレーディングシステムは、まさにマジシャンのシンボルを使ったシンプルな原理に基づいているためです。1つのシステムを2つに分けて、通常のMathAbs( OrderMagicNumber() ) 関数を使って注文をフィルタリングする方がはるかに簡単なので。

all 64.実を言うと符号付きや符号なしのタイプに固執しないこと。これは、コンパイラが算術演算が正しいことを確認するためです（符号付き値によっては、論理演算または算術演算への右ビットシフトがあります）。

同じサイズのデータの転送（割り当て）や符号なしキャスティングの際に情報が失われることはない。ULONG_MAXを前後にバウンドさせてみてください。Long-ulongのアサインメントとバックを試してみてください。構造コピーをしてみる。

一番いいのは、自分で確かめることです。そうすれば、この疑問は一挙に解決する。

 
MetaDriver:

ここでもう一つ、考えることがあります。やってみて ください。// 結果を報告する。;)

完了！コードの14行目をL.l = 4548887299649496524に置き換えてください。

MqlTradeRequestの 構造体の説明から、magicはulong型であり、定数LONG_MAXより 大きな値を割り当てることができることがわかる。 しかし、その機能 ...GetInteger() 関数は long 型を扱うように設計されているので、マジック値はこれらの関数で暗黙のうちに long 型にキャストされます。しかし，long型とulong型の変数は一対一に対応しているため，マジック値と...の関数が返す結果を比較すると，ulong型の変数が返されることになります．GetInteger() 関数では、明示的な型変換を安全に行うことができます (例: magic == (ulong)OrderGetInteger(ORDER_MAGIC) )。

何度も例を示していただき、ありがとうございます。

 

stringo:

データの転送（割り当て）はもちろん、同じサイズのデータを無記名でキャストする際にも、どこにも情報が失われることはありません。ULONG_MAXを 前後にバウンドさせてみてください。Long-ulongのアサインメントとバックを試してみてください。構造コピーをしてみる。自分で納得して、神話を広めてはいけない。

すでに試してみましたが、型を強制すると必要な結果が返ってきます（まあ、もう一回「ダイヤモンドでダンス」は追加でやらなければならないかもしれませんが）。でも、それほど重要ではありません）。

ビックおじさん

CExpert クラスをulongに変更します。

マジックで負の値を使う人は、返さなければならないもの／設定しなければならないものを強制的に指定しなければならなくなるので、良いアイデアだと思います。

また、ドキュメントにlongやulongだけでなく、その両方の型（例えば "long / ulong "のように）を示してくれると非常にうれしいです。

 
stringo:

データ転送（代入）時や、同じサイズの データを文字無しでキャストする際にも、情報はどこにも失われない。

追加質問：double->longの転送時に情報を保持するエレガントな方法はありますか？
1...789101112131415161718192021...277
新しいコメント