위협 Market Watch의 보이지 않는 상징에 대한 주제입니다. 스크립트 시작 단계(Enter 키를 누르고 "USDJPY" 입력) 전에 USDJPY 차트를 열려고 하면 아무 것도 작동하지 않습니다. 스크립트를 실행한 후 작동하면 작동합니다. 시장 개요는 변경되지 않았지만.
위협 Market Watch의 보이지 않는 상징에 대한 주제입니다. 스크립트 시작 단계(Enter 키를 누르고 "USDJPY" 입력) 전에 USDJPY 차트를 열려고 하면 아무 것도 작동하지 않습니다. 스크립트를 실행한 후 작동하면 작동합니다. 시장 개요는 변경되지 않았지만.
이 루프를 스크립트 시작 부분에 추가하십시오.
for ( int i = 0 ; i < SymbolsTotal ( true ); i++)
Print ( SymbolName (i, true ));
그리고 얼마나 많은 문자가 인쇄되는지 확인하십시오.
처음 시작할 때 AUDJPY에 대한 액세스는 시장 개요에 AUDUSD 및 USDJPY만 추가하고 이러한 쌍을 통한 두 번째 액세스에서만 기호 속성을 받습니다. 이것이 제 경우에 OrderCalcMargin에 문제를 일으키는 원인입니다.
이것은 다시 한 번 C ++ 인라인 키워드의 유용성을 증명합니다(여기에는 그것이 구식이라는 의견이 있었습니다). 무엇보다도 인라인은 실제로 프로그래머가 함수 매개변수의 평가 순서 사용을 거부한다는 것을 의미하며 컴파일러가 함수를 인라인으로 만들기로 결정하면 컴파일러는 직접 평가 순서를 더 효율적으로 사용할 수 있습니다(역순 평가는 호출된 함수에 대해서만 분명히 효과적입니다). 동시에 컴파일러가 인라인이 아닌 함수를 인라인으로 만들기로 결정하면 효율성 손실로 이어지는 경우에도 (일반) 역 평가 순서를 사용해야 합니다. 함수 인라인)
버그 재현
결과는
재시작
저것들. SYMBOL_TRADE_TICK_VALUE 는 Sleep()이 완료되지 않는 한 처음 실행할 때 0을 반환합니다.
위협 Market Watch의 보이지 않는 상징에 대한 주제입니다. 스크립트 시작 단계(Enter 키를 누르고 "USDJPY" 입력) 전에 USDJPY 차트를 열려고 하면 아무 것도 작동하지 않습니다. 스크립트를 실행한 후 작동하면 작동합니다. 시장 개요는 변경되지 않았지만.
버그 재현
결과는
재시작
저것들. SYMBOL_TRADE_TICK_VALUE 는 Sleep()이 완료되지 않는 한 처음 실행할 때 0을 반환합니다.
위협 Market Watch의 보이지 않는 상징에 대한 주제입니다. 스크립트 시작 단계(Enter 키를 누르고 "USDJPY" 입력) 전에 USDJPY 차트를 열려고 하면 아무 것도 작동하지 않습니다. 스크립트를 실행한 후 작동하면 작동합니다. 시장 개요는 변경되지 않았지만.
이 루프를 스크립트 시작 부분에 추가하십시오.
그리고 얼마나 많은 문자가 인쇄되는지 확인하십시오.
처음 시작할 때 AUDJPY에 대한 액세스는 시장 개요에 AUDUSD 및 USDJPY만 추가하고 이러한 쌍을 통한 두 번째 액세스에서만 기호 속성을 받습니다. 이것이 제 경우에 OrderCalcMargin에 문제를 일으키는 원인입니다.
이것은 여러 번 작성되었습니다. 어떤 이유로 작동하지 않습니다.
여러분, 안녕하세요!
초보자를 도와주세요.
최고가 검색 기능이 실행되었습니다. 특정 가격 최대값으로 코드 BAR NUMBER를 계산하고 반환하는 방법은 무엇입니까?
이 루프를 스크립트 시작 부분에 추가하십시오.
그리고 얼마나 많은 문자가 인쇄되는지 확인하십시오.
처음 시작할 때 AUDJPY에 대한 액세스는 시장 개요에 AUDUSD 및 USDJPY만 추가하고 이러한 쌍을 통한 두 번째 액세스에서만 기호 속성을 받습니다. 이것이 제 경우에 OrderCalcMargin에 문제를 일으키는 원인입니다.
나는 그들이 이것을 처리하는 방법을 결정할 것이라고 생각합니다
서비스 데스크에서 답변을 받았습니다. 그들은 그것을 고칠 것입니다.
고맙습니다.
SD에 신청서를 제출한 "주변" 버그에 대해 OrderCalcMargin()
MQL4/5 도움말에 직접적인 모순 이 있는지 확신하기 어렵습니다.
... 매개변수는 함수에 거꾸로 전달 된다는 점을 기억해야 합니다. 즉 , 가장 최근의 매개변수가 먼저 계산되어 전달된 다음 끝에서 두 번째 매개변수가 전달되는 식 입니다. 여는 괄호 다음에 가장 먼저 오는 매개변수가 평가되고 차례로 마지막에 전달됩니다.
... 표현식 x1,..., xn의 실행 순서는 보장 됩니다.
모순은 무엇입니까? 뒤에서 앞으로 - 그게 전부입니다. 반대말이 없습니다.
- 이 두 가지 권장 사항은 별도의 도움말 항목에 있습니다.
섹션에서 읽을 때
"인수 x1, x2,..., xn을 사용하여 함수 호출"
x1,....,xn 표현식의 실행 순서가 보장 됩니다. 그렇다면 어떤 순서를 생각하고 계십니까?
약 x1,...,xn 또는 약 xn,....,x1 ?
- 이 두 가지 권장 사항은 별도의 도움말 항목에 있습니다.
섹션에서 읽을 때
"인수 x1, x2,..., xn을 사용하여 함수 호출"
x1,....,xn 표현식의 실행 순서가 보장 됩니다. 그렇다면 어떤 순서를 생각하고 계십니까?
약 x1,...,xn 또는 약 xn,....,x1 ?
네, 맞습니다. 혼란스럽습니다.
그러나 어떤 경우에도 인수 전달의 특정 순서에 알고리즘 논리를 배치하는 것은 나쁜 습관이라고 생각합니다. 특히 이러한 계산이 오른쪽에서 왼쪽으로 이루어질 때 코드의 이해를 혼란스럽게 합니다. 따라서 이것을 적용하면 인쇄와 같이 중요하지 않은 일부 장소에만 적용됩니다.
Print()에서 표현식이 평가되는 순서는 오른쪽에서 왼쪽입니다. 인것 같습니다... 일단은... 미리 확인도 해봤습니다 :)
MQL5 참조 \ 언어 기초 \ 연산과 표현 \기타 작업
x1, x2,..., xn 인수로 함수 호출
표현식 x1,..., xn의 실행 순서는 보장 됩니다.
이것은 다시 한 번 C ++ 인라인 키워드의 유용성을 증명합니다(여기에는 그것이 구식이라는 의견이 있었습니다).
무엇보다도 인라인은 실제로 프로그래머가 함수 매개변수의 평가 순서 사용을 거부한다는 것을 의미하며 컴파일러가 함수를 인라인으로 만들기로 결정하면 컴파일러는 직접 평가 순서를 더 효율적으로 사용할 수 있습니다(역순 평가는 호출된 함수에 대해서만 분명히 효과적입니다).
동시에 컴파일러가 인라인이 아닌 함수를 인라인으로 만들기로 결정하면 효율성 손실로 이어지는 경우에도 (일반) 역 평가 순서를 사용해야 합니다. 함수 인라인)
인라인은 평가 순서를 명시적으로 제어할 수 없는 MQL에서도 적합합니다.