if ( OrderSend (Request, Result))
_B2( HistorySelect ( 0 , INT_MAX )); // В каком месте самострел?
나는 이 논리를 본다:
거래 요청이 서버로 성공적으로 전송된 경우
전체 스토리 선택
그러나 요청이 이미 서버에서 거부되었을 수 있습니다. 검사가 없기 때문에 이 코드의 아무 것도 이를 나타내지 않습니다. 역사를 선택하는 의미가 무엇입니까? 우리는 그곳에서 무엇을 보고 싶습니까?
여기 이 두 줄의 코드에서 개인적으로 요점을 알지 못합니다. 스토리를 선택하기 전에 변경 체크가 있었다면 봤을 텐데. 물론 이 두 줄은 문제의 전체 그림을 이해하지 못할 수도 있습니다. 그러나 성공적으로 서버에 요청을 보내는 것과 전체 기록을 가져오는 것 사이의 관계는 명확하지 않습니다. 요청을 보낸 후 서버에서 성공적으로 주문을 배치하더라도 시장 주문 및 위치 목록이 변경됩니다. 역사적 목록은 어떻습니까?
그러나 요청이 이미 서버에서 거부되었을 수 있습니다. 검사가 없기 때문에 이 코드의 아무 것도 이를 나타내지 않습니다. 역사를 선택하는 의미가 무엇입니까? 우리는 그곳에서 무엇을 보고 싶습니까?
여기 이 두 줄의 코드에서 개인적으로 요점을 알지 못합니다. 스토리를 선택하기 전에 변경 체크가 있었다면 봤을 텐데. 물론 이 두 줄은 문제의 전체 그림을 이해하지 못할 수도 있습니다. 그러나 성공적으로 서버에 요청을 보내는 것과 전체 기록을 가져오는 것 사이의 관계는 명확하지 않습니다. 요청을 보낸 후 서버에서 성공적으로 주문을 배치하더라도 시장 주문 및 위치 목록이 변경됩니다. 역사적 목록은 어떻습니까?
이 스레드는 Expert Advisors 작성 방법을 배우기 위한 것이 아닙니다. 그리고 터미널의 약점을 없애기 위해. 개발자가 이해하려면 간단하고 간결하며 재현 가능한 코드가 필요합니다. 나는 나 자신을 위해 그런 것을 쓰지 않습니다. 사실, 전투 고문은 브레이크를 기록합니다. 나는 파기 시작했고, 누군가(손으로라도) 위치를 수정할 때 브레이크가 발생한다는 것을 이해합니다. 이것은 물론 히스토리가 변경되지는 않지만 히스토리 캐시를 플러시합니다.
코드는 문제를 완벽하게 보여줍니다. 불필요한 검사로 재생 코드를 오염시켜서는 안 됩니다. 그 임무는 문제를 명확히 하는 것입니다. 그리고 그들이 그것을 고칠 때 - 모든 것이 지금 올바르게 작동하고 있음을 증명하십시오.
당연히 Expert Advisors\indicators\scripts는 실행되지 않고 수동 빌드만 실행됩니다. 지정된 지연은 모든 최신 64비트 태블릿에서 재생됩니다. i7에 컴퓨터가 있다면 그러한 지연이 발생하지 않았음을 인정합니다.
apk 또는 ekzeshnik이 느려집니까?
다른 터미널에서 최적화는 가능한 8개 중 6개의 로컬 에이전트에서 병렬로 실행됩니다.
이것이 네트워크 중단인 경우 Market Watch에서 마지막 틱을 가져오고 틱 기록에서 마지막 틱을 가져오는 데 영향을 미치는 이유는 무엇입니까?
동일한 세그먼트에 있는 터미널의 ZY 로그입니다.
이것이 네트워크 중단인 경우 Market Watch에서 마지막 틱을 가져오고 틱 기록에서 마지막 틱을 가져오는 데 영향을 미치는 이유는 무엇입니까?
주의 깊게 분석한 결과 CopyTicks가 네트워크 중단 중에 느려지는 것으로 나타났습니다.
음 우선, 참고로
" 구조의 기본 검사(포인터 검사)가 성공한 경우 true가 반환 됩니다. 이는 거래 작업의 성공적인 실행을 나타내지 않습니다 . 함수 실행 결과에 대한 자세한 설명을 얻으려면 다음 필드를 분석해야 합니다. 결과 구조 . "
둘째, 논리에 따르면 주문이 열리면 주문 목록에 추가하지 않고 캐시를 완전히 무효화합니까?)
여기에서 할 수 있습니다. 예를 들어 하루에 한 번 무효화할 수 있지만 이렇게 하면 Expert Advisor의 속도가 크게 향상됩니다.
먼저
코드를 올바르게 이해하려면 코드를 실행하거나 시트에서 잘 읽어야 합니다.
둘째, 논리에 따르면 주문이 열리면 주문 목록에 추가하지 않고 캐시를 완전히 무효화합니까?)
주문 목록은 변경되지 않습니다. 코드 읽기 .
코드를 올바르게 이해하려면 코드를 실행하거나 시트에서 잘 읽어야 합니다.
주문 목록은 변경되지 않습니다. 코드 읽기 .
바로 여기에
나는 이 논리를 본다:
그러나 요청이 이미 서버에서 거부되었을 수 있습니다. 검사가 없기 때문에 이 코드의 아무 것도 이를 나타내지 않습니다. 역사를 선택하는 의미가 무엇입니까? 우리는 그곳에서 무엇을 보고 싶습니까?
여기 이 두 줄의 코드에서 개인적으로 요점을 알지 못합니다. 스토리를 선택하기 전에 변경 체크가 있었다면 봤을 텐데. 물론 이 두 줄은 문제의 전체 그림을 이해하지 못할 수도 있습니다. 그러나 성공적으로 서버에 요청을 보내는 것과 전체 기록을 가져오는 것 사이의 관계는 명확하지 않습니다. 요청을 보낸 후 서버에서 성공적으로 주문을 배치하더라도 시장 주문 및 위치 목록이 변경됩니다. 역사적 목록은 어떻습니까?
바로 여기에
나는 이 논리를 본다:
그러나 요청이 이미 서버에서 거부되었을 수 있습니다. 검사가 없기 때문에 이 코드의 아무 것도 이를 나타내지 않습니다. 역사를 선택하는 의미가 무엇입니까? 우리는 그곳에서 무엇을 보고 싶습니까?
여기 이 두 줄의 코드에서 개인적으로 요점을 알지 못합니다. 스토리를 선택하기 전에 변경 체크가 있었다면 봤을 텐데. 물론 이 두 줄은 문제의 전체 그림을 이해하지 못할 수도 있습니다. 그러나 성공적으로 서버에 요청을 보내는 것과 전체 기록을 가져오는 것 사이의 관계는 명확하지 않습니다. 요청을 보낸 후 서버에서 성공적으로 주문을 배치하더라도 시장 주문 및 위치 목록이 변경됩니다. 역사적 목록은 어떻습니까?
if - 컴파일러 경고 를 제거합니다. 그리고 아무것도 아닙니다.
이 스레드는 Expert Advisors 작성 방법을 배우기 위한 것이 아닙니다. 그리고 터미널의 약점을 없애기 위해. 개발자가 이해하려면 간단하고 간결하며 재현 가능한 코드가 필요합니다. 나는 나 자신을 위해 그런 것을 쓰지 않습니다. 사실, 전투 고문은 브레이크를 기록합니다. 나는 파기 시작했고, 누군가(손으로라도) 위치를 수정할 때 브레이크가 발생한다는 것을 이해합니다. 이것은 물론 히스토리가 변경되지는 않지만 히스토리 캐시를 플러시합니다.
코드는 문제를 완벽하게 보여줍니다. 불필요한 검사로 재생 코드를 오염시켜서는 안 됩니다. 그 임무는 문제를 명확히 하는 것입니다. 그리고 그들이 그것을 고칠 때 - 모든 것이 지금 올바르게 작동하고 있음을 증명하십시오.
코드를 올바르게 이해하려면 코드를 실행하거나 시트에서 잘 읽어야 합니다.
주문 목록은 변경되지 않습니다. 코드 읽기 .
내가 시력을 아주 잘 읽는 독자라고 생각해 주세요. :)
이 코드를 어딘가에서 가져왔고 다른 곳에서 아직 실행 중인 새 위치를 생성했습니다. 맞습니까?
그렇지 않으면 코드의 요점은 현재 위치의 TP를 업데이트하고 이를 위해 캐시를 무효화하는 것인데, 이것도 매우 이상합니다.
이 두 경우 모두 캐싱을 최적화하는 데 논리가 사용되지 않습니다. 또한 솔루션을 확장할 수 없습니다. 역사의 성장은 브레이크의 증가로 이어집니다.
코드는 문제를 완벽하게 보여줍니다. 불필요한 검사로 재생 코드를 오염시켜서는 안 됩니다. 그 임무는 문제를 명확히 하는 것입니다. 그리고 그들이 그것을 고칠 때 - 모든 것이 지금 올바르게 작동하고 있음을 증명하십시오.
즉, 귀하의 논리에 따르면 이 코드는
프로세서의 브레이크를 보여줍니까?
이 코드를 어딘가에서 가져왔고 다른 곳에서 아직 실행 중인 새 위치를 생성했습니다. 맞습니까?
즉, 귀하의 논리에 따르면 이 코드는
프로세서의 브레이크를 보여줍니까?