그리고 이제 요점으로, 대화에 나타나는 예에서 결과가 mql == 12인 이유와 그것이 손가락에서 빨려나간 것인지 아닌지는 중요하지 않습니다. 접미사와 접두사 연산의 차이로, 결과는 == 13이어야 합니다.
추신. 더 이상 주장하지 않습니다. 왜냐하면 이제 확인하고 실제로 접두사와 접두사에 차이가 있지만 위의 질문은 컴파일하는 동안 언어에 분명히 충분한 모호성이 있다고 믿는 이유를 제공하고 분기의 누군가를 공격하기 전에 이러한 UB를 처리합니다. 그것으로 할
그건 그렇고, 나는 이미 삽질 된 인증서를 봅니다))
무례하지 마십시오.
누가 결과가 13이어야 한다고 말했습니까? 다시 말하지만, 부작용이 있는 결과는 최적화에 크게 의존합니다. 이러한 표현식에 최적화가 적용되지 않은 경우에도 구현이 시작됩니다. 즉, 사용 직후 또는 표현식이 평가된 후 변수 값을 변경하는 것입니다. 어떤 구현이 올바른가요?
우리는 UB를 다루지 않을 것이므로 정의되지 않고 명시적으로 "이를 수행하지 마십시오"라고 썼습니다.
자격증은 어디서 긁어모으셨나요? 그래서 1월 18일자 MetaEditor 빌드 1755에서 MQL5 참조를 열었습니다. 같은게 쓰여있다
한 프로그래밍 환경에서 다른 프로그래밍 환경으로 위의 표현식을 이동하는 동안 계산 문제가 발생할 수 있습니다(예: Borland C++에서 MQL5로). 일반적으로 계산 순서는 컴파일러 구현에 따라 다릅니다. 실제로 사후 감소(사후 증가)를 구현하는 두 가지 방법이 있습니다.
전체 표현식을 계산 한후 변수에 사후 감소(사후 증가)가 적용됩니다.
사후 감소 (사후 증가)는 작업에서 즉시 변수에 적용됩니다.
현재 사후 감소(사후 증가) 계산의 첫 번째 방법은 MQL5에서 구현됩니다. 그러나이 특성을 알고 있더라도 사용을 실험하는 것은 권장하지 않습니다.
누가 결과가 13이어야 한다고 말했습니까? 다시 말하지만, 부작용이 있는 결과는 최적화에 크게 의존합니다. 이러한 표현식에 최적화가 적용되지 않은 경우에도 구현이 시작됩니다. 즉, 사용 직후 또는 표현식이 평가된 후 변수 값을 변경하는 것입니다. 어떤 구현이 올바른가요?
우리는 UB를 다루지 않을 것이므로 정의되지 않고 명시적으로 "이를 수행하지 마십시오"라고 썼습니다.
자격증은 어디서 긁어모으셨나요? 그래서 1월 18일자 MetaEditor 빌드 1755에서 MQL5 참조를 열었습니다. 같은게 쓰여있다
한 프로그래밍 환경에서 다른 프로그래밍 환경으로 위의 표현식을 이동하는 동안 계산 문제가 발생할 수 있습니다(예: Borland C++에서 MQL5로). 일반적으로 계산 순서는 컴파일러 구현에 따라 다릅니다. 실제로 사후 감소(사후 증가)를 구현하는 두 가지 방법이 있습니다.
전체 표현식을 계산 한후 변수에 사후 감소(사후 증가)가 적용됩니다.
사후 감소 (사후 증가)는 작업에서 즉시 변수에 적용됩니다.
현재 사후 감소(사후 증가) 계산의 첫 번째 방법은 MQL5에서 구현됩니다. 그러나이 특성을 알고 있더라도 사용을 실험하는 것은 권장하지 않습니다.
귀하의 원래 진술은 접미사와 접두사 작업 사이에 차이가 없다는 것입니다. 안 그래?
나는 무례한 것이 아닙니다. 대화를 시작한 위치에주의를 기울이십시오. 나도 몰랐던 코드를 실행해야 했다 - 슈퍼
참조에 따르면 - 예, 심하게 삽질되었습니다. (약 2년 전) mql에서 접미사 및 접두사 연산으로 알아냈을 때, 지금은 분명히 기억나지 않는 이 자료
일반적으로 주제가 닫혔고 이 차이점이 도입되었으며 정상적으로 완료되었습니다. 변경 중임을 경고하기만 하면 됩니다.
. ... Rick D. ... . : RETAIL_HEDGING 계정 유형 인 포지션의 부분 청산에 대한 질문을 알려주세요. 예를 들어, 나는 전문가로부터 포지션의 절반을 청산하고, 더 작은 로트를 가진 새로운 주문은 자동으로 개설되어야 합니다. 그렇다면 터미널에 새로운 주문이 보장되는 시점은 어디일까요? PositionClosePartial 직후에 나타날 필요는 없고 OnTrade 어딘가에서 포착해야 한다는 것을 올바르게 이해하고 있습니까?
나는 내 자신의 질문에 대답하려고 노력할 것이다. PositionClosePartial이 호출되면 마감된 주문 티켓은 CTrade::ResultOrder()로 반환되고 포지션 티켓은 동일하게 유지되지만 포지션 자체는 감소된 로트가 됩니다. PositionClosePartial에 대한 호출이 한 트랜잭션에서 위치의 동기 감소와 주문 기록의 변경으로 이어진다는 결론을 내리려고 노력할 것입니다.
그리고 당신의 이러한 예가 순전히 이론적이라는 사실에도 불구하고. 순수하게 학생들을 위해. 제정신이 아닌 프로그래머는 이것을 프로덕션으로 출시하지 않을 것입니다.
접미사 및 접두사 증가 및 감소는 실제로 주로 루프에서 사용됩니다. 증가 및 감소라고 합니다!
다음은 예입니다.
그리고
접두사와 후위 연산이 같은 방식으로 작동한다고 주장하면 깃발은 손에 있고 북은 목에 있습니다.
접두사 증분의 경우 마지막 반복에서 초기화되지 않은 0 배열 요소와 배열 범위를 벗어남 오류가 발생합니다.
니 마음에 안 닿을지도 몰라 다시 질문할게
당신이 선택한 것은 더 이상 눈에 없습니다?
그리고 이제 요점으로, 대화에 나타나는 예에서 결과가 mql == 12인 이유와 그것이 손가락에서 빨려들어가는지 여부는 중요하지 않습니다. 접미사와 접두사 연산의 차이로, 결과는 == 13이어야 합니다.
추신. 더 이상 주장하지 않습니다. 왜냐하면 이제 확인하고 실제로 접두사와 접두사에 차이가 있지만 위의 질문은 컴파일하는 동안 언어에 분명히 충분한 모호성이 있다고 믿는 이유를 제공하고 분기의 누군가를 공격하기 전에 이러한 UB를 처리합니다. 그것으로 할
그건 그렇고, 나는 이미 삽질 된 인증서를 봅니다))
니 마음에 안 닿을지도 몰라 다시 질문할게
당신이 선택한 것이 더 이상 눈에 띄지 않습니까?
그리고 이제 요점으로, 대화에 나타나는 예에서 결과가 mql == 12인 이유와 그것이 손가락에서 빨려나간 것인지 아닌지는 중요하지 않습니다. 접미사와 접두사 연산의 차이로, 결과는 == 13이어야 합니다.
추신. 더 이상 주장하지 않습니다. 왜냐하면 이제 확인하고 실제로 접두사와 접두사에 차이가 있지만 위의 질문은 컴파일하는 동안 언어에 분명히 충분한 모호성이 있다고 믿는 이유를 제공하고 분기의 누군가를 공격하기 전에 이러한 UB를 처리합니다. 그것으로 할
그건 그렇고, 나는 이미 삽질 된 인증서를 봅니다))
무례하지 마십시오.
누가 결과가 13이어야 한다고 말했습니까? 다시 말하지만, 부작용이 있는 결과는 최적화에 크게 의존합니다. 이러한 표현식에 최적화가 적용되지 않은 경우에도 구현이 시작됩니다. 즉, 사용 직후 또는 표현식이 평가된 후 변수 값을 변경하는 것입니다. 어떤 구현이 올바른가요?
우리는 UB를 다루지 않을 것이므로 정의되지 않고 명시적으로 "이를 수행하지 마십시오"라고 썼습니다.
자격증은 어디서 긁어모으셨나요? 그래서 1월 18일자 MetaEditor 빌드 1755에서 MQL5 참조를 열었습니다. 같은게 쓰여있다
중요 공지
정수 i=5;
정수 k = i++ + ++i;
한 프로그래밍 환경에서 다른 프로그래밍 환경으로 위의 표현식을 이동하는 동안 계산 문제가 발생할 수 있습니다(예: Borland C++에서 MQL5로). 일반적으로 계산 순서는 컴파일러 구현에 따라 다릅니다. 실제로 사후 감소(사후 증가)를 구현하는 두 가지 방법이 있습니다.
현재 사후 감소(사후 증가) 계산의 첫 번째 방법은 MQL5에서 구현됩니다. 그러나이 특성을 알고 있더라도 사용을 실험하는 것은 권장하지 않습니다.
귀하의 원래 진술은 접미사와 접두사 작업 사이에 차이가 없다는 것입니다. 안 그래?
무례하지 마십시오.
누가 결과가 13이어야 한다고 말했습니까? 다시 말하지만, 부작용이 있는 결과는 최적화에 크게 의존합니다. 이러한 표현식에 최적화가 적용되지 않은 경우에도 구현이 시작됩니다. 즉, 사용 직후 또는 표현식이 평가된 후 변수 값을 변경하는 것입니다. 어떤 구현이 올바른가요?
우리는 UB를 다루지 않을 것이므로 정의되지 않고 명시적으로 "이를 수행하지 마십시오"라고 썼습니다.
자격증은 어디서 긁어모으셨나요? 그래서 1월 18일자 MetaEditor 빌드 1755에서 MQL5 참조를 열었습니다. 같은게 쓰여있다
중요 공지
정수 i=5;
정수 k = i++ + ++i;
한 프로그래밍 환경에서 다른 프로그래밍 환경으로 위의 표현식을 이동하는 동안 계산 문제가 발생할 수 있습니다(예: Borland C++에서 MQL5로). 일반적으로 계산 순서는 컴파일러 구현에 따라 다릅니다. 실제로 사후 감소(사후 증가)를 구현하는 두 가지 방법이 있습니다.
현재 사후 감소(사후 증가) 계산의 첫 번째 방법은 MQL5에서 구현됩니다. 그러나이 특성을 알고 있더라도 사용을 실험하는 것은 권장하지 않습니다.
귀하의 원래 진술은 접미사와 접두사 작업 사이에 차이가 없다는 것입니다. 안 그래?
나는 무례한 것이 아닙니다. 대화를 시작한 위치에주의를 기울이십시오. 나도 몰랐던 코드를 실행해야 했다 - 슈퍼
참조에 따르면 - 예, 심하게 삽질되었습니다. (약 2년 전) mql에서 접미사 및 접두사 연산으로 알아냈을 때, 지금은 분명히 기억나지 않는 이 자료
일반적으로 주제가 닫혔고 이 차이점이 도입되었으며 정상적으로 완료되었습니다. 변경 중임을 경고하기만 하면 됩니다.
RETAIL_HEDGING 계정 유형 인 포지션의 부분 청산에 대한 질문을 알려주세요. 예를 들어, 나는 전문가로부터 포지션의 절반을 청산하고, 더 작은 로트를 가진 새로운 주문은 자동으로 개설되어야 합니다. 그렇다면 터미널에 새로운 주문이 보장되는 시점은 어디일까요? PositionClosePartial 직후에 나타날 필요는 없고 OnTrade 어딘가에서 포착해야 한다는 것을 올바르게 이해하고 있습니까?
이게 뭐야?
\ 도움에 따르면 - 예, 심하게 삽질되었습니다. (약 2년 전) mql에서 접미사 및 접두사 연산으로 알아냈을 때, 지금은 분명히 기억나지 않는 이 자료
일반적으로 주제가 닫혔고 이 차이점이 도입되었으며 정상적으로 완료되었습니다. 변경 중임을 경고하기만 하면 됩니다.
참고로 저는 2015년 6월부터 오래된 빌드 1159를 확인하기로 했습니다. 그의 참고 문헌에는 Slava가 인용한 모든 내용이 포함되어 있습니다. 그래서 아마도 당신은 뭔가를 혼동했습니다.
이게 뭐야?
크래시입니다 :) 서비스 데스크로 가세요!
크래시입니다 :) 서비스 데스크로 가세요!
분명히 은행을 파산 :)
분명히 은행을 파산 :)
일어난다)
일어난다)
이 오류를 현지화하는 방법을 모르겠습니다. 나는 단지 전체 대본을 포기하고 싶지 않고 모든 것을 삽질하고 싶지 않습니다 ....