너무 빽빽하고 경박하게 작성하지 않는 것이 좋습니다 (여기뿐만 아니라 다른 소스에서도). 우선 순위가 동일한 피연산자의 계산 순서는 엄격하게 설정되지 않으며 컴파일러가 자체 고려 사항에 따라 최적화 할 수 있으며 다른 부작용이 발생할 수 있습니다. 컴파일러의 내부 구현은 항상 변경되기 때문에 지금 작동한다고 해서 나중에 작동이 중단되지 않는다는 의미는 아닙니다.
너무 빽빽하고 경박하게 작성하지 않는 것이 좋습니다 (여기뿐만 아니라 다른 소스에서도). 우선 순위가 동일한 피연산자의 계산 순서는 엄격하게 설정되지 않으며 컴파일러가 자체 고려 사항에 따라 최적화 할 수 있으며 다른 부작용이 발생할 수 있습니다. 컴파일러의 내부 구현은 항상 변경되기 때문에 지금 작동한다고 해서 나중에 작동이 중단되지 않는다는 의미는 아닙니다.
건전한 조언에 감사드립니다! 안타깝게도 올바른 스타일을 위해 "간결한" 스타일에서 벗어나도록 강요하기는 어렵습니다. "잘못된" 코드가 많이 작성되고 사용되고 있습니다.
여기뿐만 아니라 다른 소스에서도 그렇게 빽빽하고 경솔한 방식으로 작성하지 않는 것이 좋습니다. 우선 순위가 동일한 피연산자의 계산 순서는 엄격하게 설정되지 않으며 컴파일러는 자체 고려 사항에 따라 최적화 할 수 있으며 다른 부작용을 얻을 수 있습니다. 컴파일러의 내부 구현은 항상 변경되기 때문에 지금 작동한다고 해서 나중에 작동이 멈추지 않는다는 의미는 아닙니다.
건전한 조언에 감사드립니다! 안타깝게도 "간결한" 스타일에서 벗어나 올바른 스타일로 바꾸기는 어렵습니다. "잘못된" 코드가 많이 작성되고 사용되고 있습니다.
저는 코드를 작업/테스트하고 다시 돌아갈 계획이 없는 경우에는 거의 항상 함수와 기타 코드를 한 줄로 압축합니다. 공간을 절약하기 위해서죠. 그리고 한 화면에서 모든 것을 볼 수 있을 때 앞뒤로 스크롤하지 않고 코드를 읽는 것이 더 편리합니다. 특히 강조 표시된 단어를 강조 표시하는 편집기에서는 더욱 그렇습니다(안타깝게도 메타에디터는 그렇지 않습니다).
Forester #: 저는 코드가 작업/테스트되고 다시 돌아갈 계획이 없는 경우 거의 항상 함수와 기타 코드를 한 줄로 축소합니다. 공간을 절약하기 위해서죠. 그리고 한 화면에서 모든 것을 볼 수 있을 때 앞뒤로 스크롤하지 않고 코드를 읽는 것이 더 편리합니다. 특히 강조 표시된 단어를 강조 표시하는 편집기에서 (불행히도 Metaeditor는 그중 하나가 아닙니다).
안타깝게도 이 방식은 컴파일러를 변경할 때 보기 어려운 오류로 이어질 수 있습니다.
그러나 컴파일러에 설정된 순서를 사용해야 하는 상황이 있습니다. 그리고 거기에서 UB가 없도록 해결하는 방법을 모르겠습니다.
최대 긴 드로다운에 대한 정보가 흥미롭습니다. 전체 문자열 배열에 대해 만들었습니다. 아직 사이트에서 코드를 업데이트하지 않았습니다. 그러나 날짜가 무엇인지 명확하지 않습니다. (내가 제안한대로) 백 / 포워드 테스트로 나누면 2 개의 테이블에서 별도로 통계를 계산해야합니다 (최대 드로 다운 기간도 거기에있을 것입니다). 그리고 한 날짜에 대해서는 너무 구체적이고 이해할 수 없습니다.
서버: 메타퀀트-데모 헤지
2페이지의 티켓 99를 처리합니다.
약간 현지화되었습니다.
EA가 무엇을 하는지는 중요하지 않습니다. 가장 중요한 것은 강조 표시된 코드로, 거래 내역에서 MT5 주문을 간단히 표시합니다: 주문의 장소, 티켓 및 주문이 내역에 입력된 시간.
내역 테이블에서 MT5 주문은 티켓이나 시간별로 정렬되지 않습니다. MQ-Tester의 이러한 동작을 개발자에게 보고하는 것이 무슨 의미가 있는지 모르겠습니다. 결국, "작업은 도를 넘었다"고 생각합니다.
따라서 저는 MQ-Tester를 표준화하지 않을 것입니다.
약간 현지화되었습니다.
EA가 무엇을 하는지는 중요하지 않습니다. 가장 중요한 것은 거래 내역에서 MT5 주문을 간단히 출력하는 전용 코드입니다: 주문 장소, 티켓 및 주문이 내역에 들어간 시간.
내역 테이블에서 MT5 주문은 티켓이나 시간별로 정렬되지 않습니다. MQ-Tester의 이러한 동작을 개발자에게 보고하는 것이 무슨 의미가 있는지 모르겠습니다. 결국, "작업은 도를 넘었다"고 생각합니다.
따라서 저는 MQ-Tester를 표준화하지 않을 것입니다.
첫 번째 테스트 거래 및 스왑 (몇 주 전에 할인 한)에서 명백한 버그를 수정할 필요가 없다면 그것은 단지 기능 일뿐입니다. 혼동 매트릭스가 더 중요합니다....
fxsaber #:
Иногда полезно знать.
너무 빽빽하고 경박하게 작성하지 않는 것이 좋습니다 (여기뿐만 아니라 다른 소스에서도). 우선 순위가 동일한 피연산자의 계산 순서는 엄격하게 설정되지 않으며 컴파일러가 자체 고려 사항에 따라 최적화 할 수 있으며 다른 부작용이 발생할 수 있습니다. 컴파일러의 내부 구현은 항상 변경되기 때문에 지금 작동한다고 해서 나중에 작동이 중단되지 않는다는 의미는 아닙니다.
너무 빽빽하고 경박하게 작성하지 않는 것이 좋습니다 (여기뿐만 아니라 다른 소스에서도). 우선 순위가 동일한 피연산자의 계산 순서는 엄격하게 설정되지 않으며 컴파일러가 자체 고려 사항에 따라 최적화 할 수 있으며 다른 부작용이 발생할 수 있습니다. 컴파일러의 내부 구현은 항상 변경되기 때문에 지금 작동한다고 해서 나중에 작동이 중단되지 않는다는 의미는 아닙니다.
건전한 조언에 감사드립니다! 안타깝게도 올바른 스타일을 위해 "간결한" 스타일에서 벗어나도록 강요하기는 어렵습니다. "잘못된" 코드가 많이 작성되고 사용되고 있습니다.
// 지정된 시간부터 최대 드로다운 기간입니다.
여기뿐만 아니라 다른 소스에서도 그렇게 빽빽하고 경솔한 방식으로 작성하지 않는 것이 좋습니다. 우선 순위가 동일한 피연산자의 계산 순서는 엄격하게 설정되지 않으며 컴파일러는 자체 고려 사항에 따라 최적화 할 수 있으며 다른 부작용을 얻을 수 있습니다. 컴파일러의 내부 구현은 항상 변경되기 때문에 지금 작동한다고 해서 나중에 작동이 멈추지 않는다는 의미는 아닙니다.
나는 그냥
마음에 들지 않아요. 하루는 24시간이 아니라 25시간입니다.Forester #:
C даты начала форварда?
누구든
무엇이 잘못되었나요?
인쇄용 문자열이 형성되는 순서가 명확하지 않습니다. 오른쪽에서 왼쪽으로 가면 결과가 의도 한 것과 다릅니다.
이런 경우에도 모호함이 있었으면 좋겠어요.
건전한 조언에 감사드립니다! 안타깝게도 "간결한" 스타일에서 벗어나 올바른 스타일로 바꾸기는 어렵습니다. "잘못된" 코드가 많이 작성되고 사용되고 있습니다.
그리고 한 화면에서 모든 것을 볼 수 있을 때 앞뒤로 스크롤하지 않고 코드를 읽는 것이 더 편리합니다. 특히 강조 표시된 단어를 강조 표시하는 편집기에서는 더욱 그렇습니다(안타깝게도 메타에디터는 그렇지 않습니다).
저는 코드가 작업/테스트되고 다시 돌아갈 계획이 없는 경우 거의 항상 함수와 기타 코드를 한 줄로 축소합니다. 공간을 절약하기 위해서죠.
그리고 한 화면에서 모든 것을 볼 수 있을 때 앞뒤로 스크롤하지 않고 코드를 읽는 것이 더 편리합니다. 특히 강조 표시된 단어를 강조 표시하는 편집기에서 (불행히도 Metaeditor는 그중 하나가 아닙니다).
안타깝게도 이 방식은 컴파일러를 변경할 때 보기 어려운 오류로 이어질 수 있습니다.
그러나 컴파일러에 설정된 순서를 사용해야 하는 상황이 있습니다. 그리고 거기에서 UB가 없도록 해결하는 방법을 모르겠습니다.
누구에게나.
최대 긴 드로다운에 대한 정보가 흥미롭습니다. 전체 문자열 배열에 대해 만들었습니다. 아직 사이트에서 코드를 업데이트하지 않았습니다.
그러나 날짜가 무엇인지 명확하지 않습니다. (내가 제안한대로) 백 / 포워드 테스트로 나누면 2 개의 테이블에서 별도로 통계를 계산해야합니다 (최대 드로 다운 기간도 거기에있을 것입니다).
그리고 한 날짜에 대해서는 너무 구체적이고 이해할 수 없습니다.