확인할 시간이 있었습니다: 예, 트릭이 실패했습니다. 시각적 및 비시각적...(테스터의 상수 차트ID)에 대해 ChartID()=12345가 반환되었습니다.
그러나 화면이 없는 경우 ChartGetInteger(ChartID(),CHART_WIDTH_IN_PIXELS)는 정직한 -1을 반환합니다. 이 함수를 사용하여 무언가를 출력할 장소가 있는지 여부와 같은 물리학을 결정할 수 있습니다. 플래그가 많고 VPS에 무엇이 있는지 전혀 알 수 없기 때문입니다.
이렇게 할 수 없습니다 :-)) 생성자에서 부모 클래스의 OnAttach가 호출됩니다. 그리고 일반 액세스 중에 - 자식 클래스의.
이해할 수 없으니 외워야 합니다 :-))
왜 이해가 불가능할까요? 가상 메서드 표에서 메서드에 대한 포인터의 초기화는 생성자에서 이루어집니다. 부모 클래스의 생성자가 먼저 호출된 다음 후속 클래스의 생성자가 호출됩니다. 따라서 상위 클래스 생성자의 본문이 실행될 때 가상 메서드 테이블에서 포인터는 기본 클래스 메서드의 주소를 가리킵니다.
추신. 이것은 C++를 배워야 하는지에 대한 영원한 촐리바를 위한 것입니다. 벼락치기가 아니라 사물의 본질을 파고들면서 공부하면 그런 것들이 자명해집니다).
이해하기 어려운 이유는 무엇인가요? 가상 메서드 테이블에서 메서드에 대한 포인터의 초기화는 생성자에서 이루어집니다. 부모 클래스의 생성자가 먼저 호출된 다음 후속 클래스의 생성자가 호출됩니다. 따라서 부모 클래스 생성자의 본문이 실행될 때 포인터는 가상 메서드 테이블에서 기본 클래스 메서드의 주소를 가리킵니다.
추신. 이것은 C++를 배워야 하는지에 대한 영원한 촐리바를 위한 것입니다. 벼락치기가 아니라 사물의 본질을 파헤치면서 공부하면 그런 것들이 자명해집니다).
모든 것이 가능한 스크립트 이후에는 "생성자가 가상이 될 수 없다"는 것이 약간 놀랍습니다 :-)))
Все мы знаем, что в C++ нет такого понятия как виртуальный конструктор , который бы собирал нужный нам объект в зависимости от каких-либо входных параметров на этапе выполнения. Обычно для этих целей используется параметризованный фабричный метод (Factory Method) . Однако мы можем сделать «ход конем» и сымитировать поведение виртуального...
무슨 뜻인가요? 좀 더 자세히 설명해 주시겠어요?
확인할 시간이 있었습니다: 예, 트릭이 실패했습니다. 시각적 및 비시각적...(테스터의 상수 차트ID)에 대해 ChartID()=12345가 반환되었습니다.
그러나 화면이 없는 경우 ChartGetInteger(ChartID(),CHART_WIDTH_IN_PIXELS)는 정직한 -1을 반환합니다. 이 함수를 사용하여 무언가를 출력할 장소가 있는지 여부와 같은 물리학을 결정할 수 있습니다. 플래그가 많고 VPS에 무엇이 있는지 전혀 알 수 없기 때문입니다.
또 다른 갑작스러운 MQL의 뉘앙스 - 가상 메서드는 생성자에서 호출되지 않습니다.
코드에서
이렇게 할 수 없습니다 :-)) 부모 클래스의 OnAttach는 생성자에서 호출됩니다 ; 그리고 정상적인 액세스 중에 - 자식 클래스의.
이해할 수 없으니 외워야 합니다 :-))
MQL의 또 다른 갑작스러운 뉘앙스 - 가상 메서드는 생성자에서 호출되지 않습니다.
코드에서
이렇게 할 수 없습니다 :-)) 생성자에서 부모 클래스의 OnAttach가 호출됩니다. 그리고 일반 액세스 중에 - 자식 클래스의.
이해할 수 없으니 외워야 합니다 :-))
왜 이해가 불가능할까요? 가상 메서드 표에서 메서드에 대한 포인터의 초기화는 생성자에서 이루어집니다. 부모 클래스의 생성자가 먼저 호출된 다음 후속 클래스의 생성자가 호출됩니다. 따라서 상위 클래스 생성자의 본문이 실행될 때 가상 메서드 테이블에서 포인터는 기본 클래스 메서드의 주소를 가리킵니다.
추신. 이것은 C++를 배워야 하는지에 대한 영원한 촐리바를 위한 것입니다. 벼락치기가 아니라 사물의 본질을 파고들면서 공부하면 그런 것들이 자명해집니다).
이해하기 어려운 이유는 무엇인가요? 가상 메서드 테이블에서 메서드에 대한 포인터의 초기화는 생성자에서 이루어집니다. 부모 클래스의 생성자가 먼저 호출된 다음 후속 클래스의 생성자가 호출됩니다. 따라서 부모 클래스 생성자의 본문이 실행될 때 포인터는 가상 메서드 테이블에서 기본 클래스 메서드의 주소를 가리킵니다.
추신. 이것은 C++를 배워야 하는지에 대한 영원한 촐리바를 위한 것입니다. 벼락치기가 아니라 사물의 본질을 파헤치면서 공부하면 그런 것들이 자명해집니다).
모든 것이 가능한 스크립트 이후에는 "생성자가 가상이 될 수 없다"는 것이 약간 놀랍습니다 :-)))
모든 것이 가능한 스크립트 이후에는 "생성자가 가상이 될 수 없다"는 것이 조금 놀랍습니다 :-)
"문제"에 대한 해결책이 있습니다 : https://habr.com/ru/post/64369/.
추신. 물론 정확히 동일하지는 않지만 일반적인 생각의 방향은 다음과 같습니다.
모든 것이 가능한 스크립트 이후에는 "생성자가 가상이 될 수 없다"는 것이 조금 놀랍습니다 :-)
예상치 못하셨나요?
HiLow::OnAttach가 호출되었다고 상상해 보세요. HiLow에 새 필드가 있고 OnAttach가 이를 읽으면 "초기화되지 않은 변수 사용"이 발생하게 됩니다(HiLow 생성자가 아직 실행을 시작하지 않았기 때문에).
포지션_시간_업데이트는 포지션의 로트를 변경할 때만 관련이 있습니다. 예를 들어, 모든 유형의 계좌에서 포지션을 부분적으로 청산하거나 네팅을 리필하는 경우입니다.
SL/TP 레벨의 변경은 POSITION_TIME_UPDATE에 영향을 미치지 않습니다.
다시 말해, POSITION_TIME_UPDATE는 거래 내역(거래)에 반영된 변경 사항만 영향을 받습니다. SL/TP 레벨은 이러한 수정에 속하지 않으므로 영향을 받지 않습니다.
예, 실제로 실제 계좌에서는 그렇습니다.
그러나 Expert Advisor를 구축 한 후 테스터에서 시도한 결과 테스터에서 SL / TP 레벨의 수정이 POSITION_TIME_UPDATE에 영향을 미치는 것으로 나타났습니다.
다음은 로그에서 발췌한 내용입니다.
여기에서는 포지션 오픈 시간을 노란색으로 강조 표시한 다음 (다음 틱에서 ) SL 및 TP를 수정 (배치)한 시간을 빨간색으로 강조 표시했습니다. 그런 다음 인쇄를 사용하여 POSITION_TIME 및 POSITION_TIME_UPDATE 시간을 확인합니다.
SL과 TP의 수정 시간이 같은 초 이내인 경우 POSITION_TIME과 POSITION_TIME_UPDATE 시간은 당연히 동일합니다.
정보를 제공해 주셔서 감사합니다!
주문이 부분적으로 실행되면 ORDER_TIME_SETUP_MSC 필드가 변경됩니다.
따라서 DEAL_TIME_MSC는 해당 주문의 ORDER_TIME_SETUP_MSC보다 작을 수 있습니다.
예시.