찻주전자의 질문 - 페이지 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 :

여러분, 저는 솔직히 혼란스럽습니다. 당신은 평평한 바닥에 떠 있습니다. 절대적으로 균일합니다.

나는 단지 이 "진지한" 대화에 끼어 사과하고 싶었다. 예, 내가 담배를 사러 갔을 때 그들은 나를 때렸습니다.

그리고 결국 "인형"이 아닌 것처럼? 그리고 그러한 "boo-boo-boo"는 처음부터 불을 붙였습니다.

CExpert 클래스에서 ulong에 대해 수정하겠습니다.

 
Renat :

당신은 잘못.

네. 유형 변환을 잊어 버렸습니다.

 
uncleVic :

그리고 결국 "인형"이 아닌 것처럼?

나는 많은 문제에 대한 찻주전자입니다. 그래서 long을 반환하도록 설계된 함수가 ULONG_MAX-1을 반환하는 방법을 이해할 수 없습니다. 정수 유형을 사용한 피상적 작업의 함정에 대해서는 거의 핸드북 자체에 기록되어 있습니다. sergeev문제 의 원인인 주문 제어를 올바르게 포착했습니다. request.magic을 ulong 유형으로 설정하면 HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 함수 도 ulong을 반환할 것으로 예상합니다. 명시적-암시적 유형 변환 없이.

여가 시간에 MetaDriver 의 예를 분석하겠습니다. ...그러나 그의 예에서 long<->ulong 유형(예: double -> int와 달리) 변환 중에 값 손실이 없다고 설명하면 추가 생각이 명확해집니다.

삼촌 빅 :

그리고 그러한 "boo-boo-boo"는 처음부터 불을 붙였습니다.

사실, "차주전자의 질문"이라는 지점은 비난이 아니라 해명을 얻기 위해 선택되었습니다.

 
Yedelkin :

나는 많은 문제에 대한 찻주전자입니다. 그래서 long을 반환하도록 설계된 함수가 ULONG_MAX-1을 반환하는 방법을 이해할 수 없습니다. 정수 유형을 사용한 피상적 작업의 함정에 대해서는 거의 핸드북 자체에 기록되어 있습니다. sergeev문제 의 원인인 주문 제어를 올바르게 포착했습니다. request.magic을 ulong 유형으로 설정하면 HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 함수 도 ulong을 반환할 것으로 예상합니다. 명시적-암시적 유형 변환 없이.

여가 시간에 MetaDriver 의 예를 분석하겠습니다. ...그러나 그의 예에서 long<->ulong 유형(예: double -> int와 달리) 변환 중에 값 손실이 없다고 설명하면 추가 생각이 명확해집니다.

사실, "차주전자의 질문"이라는 지점은 비난이 아니라 해명을 얻기 위해 선택되었습니다.

기분이 상했나? 미안, 저항할 수 없었다.
 
uncleVic :
기분이 상했나? 미안, 저항할 수 없었다.
예, 아니요, 인터넷 전쟁에서 강화가 있습니다. 나는 항상 토론을 건설적인 방향으로 이끌려고 노력합니다.
 
sergeev :

실제로는 64비트가 아니라 63비트만 사용된다(즉, 불완전한 8바이트). long 의 전체 범위를 사용하는 경우 8바이트가 됩니다.

하지만 안타깝게도...

한편으로는 ulong 마법이 MqlTradeRequest 구조로 전달됩니다. 이것은 양수 값만 지정할 수 있음을 의미합니다.

반면 PositionGetInteger / OrderGetInteger 함수 유형 을 반환합니다 . 즉, ulong 범위의 절반이 잘립니다.

전체적으로 선언된 64비트 대신 실제로는 63비트가 있는데, 일반적으로 이것은 순서 제어의 원칙에 큰 불편 을 줄 정도로 나쁘지 않습니다.

MT4와 유사한 시스템을 유지하는 것이 훨씬 더 편리합니다. 기호로 마법을 허용하십시오. 많은 거래 시스템이 마술 기호를 사용하는 간단한 원리에 따라 구축되기 때문입니다. 따라서 하나의 시스템을 두 개로 나누고 일반적인 함수 MathAbs( OrderMagicNumber() ) 를 사용하여 주문을 필터링하는 것이 훨씬 쉽습니다.

모두 64. 사실. 서명되거나 서명되지 않은 유형에 집착하지 마십시오. 이것은 컴파일러가 올바른 산술 연산을 제공하기 위한 것입니다(음, 비트 오른쪽 시프트는 부호에 따라 논리적이거나 산술적일 수 있음)

데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다. ULONG_MAX를 앞뒤로 굴려보십시오. long-ulong을 할당하거나 그 반대로 시도하십시오. 구조를 복사해 보십시오.

가장 좋은 것은 직접 보는 것입니다. 그러면 질문이 완전히 닫힙니다.

 
MetaDriver :

여기서 또 한 가지 생각해 볼 것이 있습니다. 반드시 완료하세요! // 결과를 보고합니다. ;)

완료! 암호화에서 14번째 줄을 Ll = 4548887299649496524로 바꿉니다.

일반적으로 나는 이런 결론에 도달했습니다. MqlTradeRequest 구조에 대한 설명에서 매직이 ulong 유형임을 알 수 있습니다. LONG_MAX 상수 값보다 큰 값을 할당할 수 있습니다. 동시에 ... GetInteger() 와 같은 함수는 long 유형과 함께 작동하도록 설계되었으므로 매직 값은 이러한 함수에 의해 암시적으로 long 유형으로 캐스팅됩니다. 그러나 long 및 ulong 유형의 변수 간에는 일대일 대응 관계가 있으므로 magic 값을 ... GetInteger() 와 같은 함수에서 반환된 결과와 비교할 때 명시적 캐스트를 안전하게 사용할 수 있습니다(예: 매직 == (ulong)OrderGetInteger(ORDER_MAGIC) ).

반복되는 예시에 대한 ATP.

 

stringo :

데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다. ULONG_MAX 를 앞뒤로 굴려보십시오. long-ulong을 할당하거나 그 반대로 시도하십시오. 구조를 복사해 보십시오. 자신을보고 신화를 퍼뜨리지 마십시오

나는 이미 시도했는데, 유형이 강제되면 필요한 결과가 반환됩니다(음, 아마도 "탬버린과 함께 춤을 추는" 몇 가지 더 추가로 수행되어야 할 것입니다. 그러나 이것은 더 이상 그렇게 중요하지 않습니다).

삼촌 빅 :

CExpert 클래스에서 ulong에 대해 수정하겠습니다.

내 생각에 좋은 점은 magick에서 음수 값을 사용하는 사람은 반환/설정해야 할 항목을 적용해야 한다는 것입니다.

문서에 long 또는 ulong뿐만 아니라 이러한 유형(예: "long / ulong")이 모두 표시되어 있으면 매우 좋습니다.

 
stringo :

데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다.

추가 질문: double -> long을 전달할 때 정보를 저장하는 우아한 방법이 있습니까?