나는 많은 문제에 대한 찻주전자입니다. 그래서 long을 반환하도록 설계된 함수가 ULONG_MAX-1을 반환하는 방법을 이해할 수 없습니다. 정수 유형을 사용한 피상적 작업의 함정에 대해서는 거의 핸드북 자체에 기록되어 있습니다. sergeev 가 문제 의 원인인 주문 제어를 올바르게 포착했습니다. request.magic을 ulong 유형으로 설정하면 HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 함수 도 ulong을 반환할 것으로 예상합니다. 명시적-암시적 유형 변환 없이.
여가 시간에 MetaDriver 의 예를 분석하겠습니다. ...그러나 그의 예에서 long<->ulong 유형(예: double -> int와 달리) 변환 중에 값 손실이 없다고 설명하면 추가 생각이 명확해집니다.
나는 많은 문제에 대한 찻주전자입니다. 그래서 long을 반환하도록 설계된 함수가 ULONG_MAX-1을 반환하는 방법을 이해할 수 없습니다. 정수 유형을 사용한 피상적 작업의 함정에 대해서는 거의 핸드북 자체에 기록되어 있습니다. sergeev 가 문제 의 원인인 주문 제어를 올바르게 포착했습니다. request.magic을 ulong 유형으로 설정하면 HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 함수 도 ulong을 반환할 것으로 예상합니다. 명시적-암시적 유형 변환 없이.
여가 시간에 MetaDriver 의 예를 분석하겠습니다. ...그러나 그의 예에서 long<->ulong 유형(예: double -> int와 달리) 변환 중에 값 손실이 없다고 설명하면 추가 생각이 명확해집니다.
전체적으로 선언된 64비트 대신 실제로는 63비트가 있는데, 일반적으로 이것은 순서 제어의 원칙에 큰 불편 을 줄 정도로 나쁘지 않습니다.
MT4와 유사한 시스템을 유지하는 것이 훨씬 더 편리합니다. 기호로 마법을 허용하십시오. 많은 거래 시스템이 마술 기호를 사용하는 간단한 원리에 따라 구축되기 때문입니다. 따라서 하나의 시스템을 두 개로 나누고 일반적인 함수 MathAbs( OrderMagicNumber() ) 를 사용하여 주문을 필터링하는 것이 훨씬 쉽습니다.
모두 64. 사실. 서명되거나 서명되지 않은 유형에 집착하지 마십시오. 이것은 컴파일러가 올바른 산술 연산을 제공하기 위한 것입니다(음, 비트 오른쪽 시프트는 부호에 따라 논리적이거나 산술적일 수 있음)
데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다. ULONG_MAX를 앞뒤로 굴려보십시오. long-ulong을 할당하거나 그 반대로 시도하십시오. 구조를 복사해 보십시오.
여기서 또 한 가지 생각해 볼 것이 있습니다. 반드시 완료하세요! // 결과를 보고합니다. ;)
완료! 암호화에서 14번째 줄을 Ll = 4548887299649496524로 바꿉니다.
일반적으로 나는 이런 결론에 도달했습니다. MqlTradeRequest 구조에 대한 설명에서 매직이 ulong 유형임을 알 수 있습니다. LONG_MAX 상수 값보다 큰 값을 할당할 수 있습니다. 동시에 ... GetInteger() 와 같은 함수는 long 유형과 함께 작동하도록 설계되었으므로 매직 값은 이러한 함수에 의해 암시적으로 long 유형으로 캐스팅됩니다. 그러나 long 및 ulong 유형의 변수 간에는 일대일 대응 관계가 있으므로 magic 값을 ... GetInteger() 와 같은 함수에서 반환된 결과와 비교할 때명시적 캐스트를 안전하게 사용할 수 있습니다(예: 매직 == (ulong)OrderGetInteger(ORDER_MAGIC) ).
데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다. ULONG_MAX 를 앞뒤로 굴려보십시오. long-ulong을 할당하거나 그 반대로 시도하십시오. 구조를 복사해 보십시오. 자신을보고 신화를 퍼뜨리지 마십시오
나는 이미 시도했는데, 유형이 강제되면 필요한 결과가 반환됩니다(음, 아마도 "탬버린과 함께 춤을 추는" 몇 가지 더 추가로 수행되어야 할 것입니다. 그러나 이것은 더 이상 그렇게 중요하지 않습니다).
삼촌 빅 :
CExpert 클래스에서 ulong에 대해 수정하겠습니다.
내 생각에 좋은 점은 magick에서 음수 값을 사용하는 사람은 반환/설정해야 할 항목을 적용해야 한다는 것입니다.
문서에 long 또는 ulong뿐만 아니라 이러한 유형(예: "long / ulong")이 모두 표시되어 있으면 매우 좋습니다.
여기서 또 한 가지 생각해 볼 것이 있습니다. 반드시 완료하세요! // 결과를 보고합니다. ;)
여러분, 저는 솔직히 혼란스럽습니다. 당신은 평평한 바닥에 떠 있습니다. 절대적으로 균일합니다.
나는 단지 이 "진지한" 대화에 끼어 사과하고 싶었다. 예, 내가 담배를 사러 갔을 때 그들은 나를 때렸습니다.
그리고 결국 "인형"이 아닌 것처럼? 그리고 그러한 "boo-boo-boo"는 처음부터 불을 붙였습니다.
CExpert 클래스에서 ulong에 대해 수정하겠습니다.
당신은 잘못.
네. 유형 변환을 잊어 버렸습니다.
그리고 결국 "인형"이 아닌 것처럼?
나는 많은 문제에 대한 찻주전자입니다. 그래서 long을 반환하도록 설계된 함수가 ULONG_MAX-1을 반환하는 방법을 이해할 수 없습니다. 정수 유형을 사용한 피상적 작업의 함정에 대해서는 거의 핸드북 자체에 기록되어 있습니다. sergeev 가 문제 의 원인인 주문 제어를 올바르게 포착했습니다. request.magic을 ulong 유형으로 설정하면 HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 함수 도 ulong을 반환할 것으로 예상합니다. 명시적-암시적 유형 변환 없이.
여가 시간에 MetaDriver 의 예를 분석하겠습니다. ...그러나 그의 예에서 long<->ulong 유형(예: double -> int와 달리) 변환 중에 값 손실이 없다고 설명하면 추가 생각이 명확해집니다.
그리고 그러한 "boo-boo-boo"는 처음부터 불을 붙였습니다.
사실, "차주전자의 질문"이라는 지점은 비난이 아니라 해명을 얻기 위해 선택되었습니다.
나는 많은 문제에 대한 찻주전자입니다. 그래서 long을 반환하도록 설계된 함수가 ULONG_MAX-1을 반환하는 방법을 이해할 수 없습니다. 정수 유형을 사용한 피상적 작업의 함정에 대해서는 거의 핸드북 자체에 기록되어 있습니다. sergeev 가 문제 의 원인인 주문 제어를 올바르게 포착했습니다. request.magic을 ulong 유형으로 설정하면 HistoryDealGetInteger() , PositionGetInteger() , OrderGetInteger() 함수 도 ulong을 반환할 것으로 예상합니다. 명시적-암시적 유형 변환 없이.
여가 시간에 MetaDriver 의 예를 분석하겠습니다. ...그러나 그의 예에서 long<->ulong 유형(예: double -> int와 달리) 변환 중에 값 손실이 없다고 설명하면 추가 생각이 명확해집니다.
사실, "차주전자의 질문"이라는 지점은 비난이 아니라 해명을 얻기 위해 선택되었습니다.
기분이 상했나? 미안, 저항할 수 없었다.
실제로는 64비트가 아니라 63비트만 사용된다(즉, 불완전한 8바이트). long 의 전체 범위를 사용하는 경우 8바이트가 됩니다.
하지만 안타깝게도...
한편으로는 ulong 마법이 MqlTradeRequest 구조로 전달됩니다. 이것은 양수 값만 지정할 수 있음을 의미합니다.
반면 PositionGetInteger / OrderGetInteger 함수 는 긴 유형 을 반환합니다 . 즉, ulong 범위의 절반이 잘립니다.
전체적으로 선언된 64비트 대신 실제로는 63비트가 있는데, 일반적으로 이것은 순서 제어의 원칙에 큰 불편 을 줄 정도로 나쁘지 않습니다.
MT4와 유사한 시스템을 유지하는 것이 훨씬 더 편리합니다. 기호로 마법을 허용하십시오. 많은 거래 시스템이 마술 기호를 사용하는 간단한 원리에 따라 구축되기 때문입니다. 따라서 하나의 시스템을 두 개로 나누고 일반적인 함수 MathAbs( OrderMagicNumber() ) 를 사용하여 주문을 필터링하는 것이 훨씬 쉽습니다.
모두 64. 사실. 서명되거나 서명되지 않은 유형에 집착하지 마십시오. 이것은 컴파일러가 올바른 산술 연산을 제공하기 위한 것입니다(음, 비트 오른쪽 시프트는 부호에 따라 논리적이거나 산술적일 수 있음)
데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다. ULONG_MAX를 앞뒤로 굴려보십시오. long-ulong을 할당하거나 그 반대로 시도하십시오. 구조를 복사해 보십시오.
가장 좋은 것은 직접 보는 것입니다. 그러면 질문이 완전히 닫힙니다.
여기서 또 한 가지 생각해 볼 것이 있습니다. 반드시 완료하세요! // 결과를 보고합니다. ;)
완료! 암호화에서 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")이 모두 표시되어 있으면 매우 좋습니다.
데이터를 전송(할당)할 때와 같은 크기의 데이터를 서명된 서명되지 않은 캐스팅할 때 정보는 어디에도 손실되지 않습니다.