하지만 개인적으로 이러한 작업을 위해 DLL이 실제로 필요하지 않다고 결정했습니다. 지금은 한 DC에서 견적을 받아 다른 DC뿐만 아니라 MetaTrader가 없는 거래를 위한 신호를 보낼 고문에 대해 생각하고 있습니다. (그런데 DukaKopy, 나는 MetaQuotes가 이 유서 깊은 중개인을 다룰 것인지 궁금합니다.).
DLL의 방향으로 생각했습니다. 하지만 공유 파일이 훨씬 안전하고 합리적이라고 판단했습니다. MetaTrader가 파일에 신호를 쓰도록 합니다. 그리고 또 다른 MetaTrader(또는 JForex, 또는 다른 사람) - 그들이 읽고 실행하게 하십시오.
하지만 개인적으로 이러한 작업을 위해 DLL이 실제로 필요하지 않다고 결정했습니다. 지금은 한 DC에서 견적을 받아 다른 DC뿐만 아니라 MetaTrader가 없는 거래를 위한 신호를 보낼 고문에 대해 생각하고 있습니다. (그런데 DukaKopy, 나는 MetaQuotes가 이 유서 깊은 중개인을 다룰 것인지 궁금합니다.).
DLL의 방향으로 생각했습니다. 하지만 공유 파일이 훨씬 안전하고 합리적이라고 판단했습니다. MetaTrader가 파일에 신호를 쓰도록 합니다. 그리고 또 다른 MetaTrader(또는 JForex, 또는 다른 사람) - 그들이 읽고 실행하게 하십시오.
예를 들어, 터미널 간 통신.
뭐 그런 변태라면 당연히 DLL은 필수 기능이지...
하지만 개인적으로 이러한 작업을 위해 DLL이 실제로 필요하지 않다고 결정했습니다. 지금은 한 DC에서 견적을 받아 다른 DC뿐만 아니라 MetaTrader가 없는 거래를 위한 신호를 보낼 고문에 대해 생각하고 있습니다. (그런데 DukaKopy, 나는 MetaQuotes가 이 유서 깊은 중개인을 다룰 것인지 궁금합니다.).
DLL의 방향으로 생각했습니다. 하지만 공유 파일이 훨씬 안전하고 합리적이라고 판단했습니다. MetaTrader가 파일에 신호를 쓰도록 합니다. 그리고 또 다른 MetaTrader(또는 JForex, 또는 다른 사람) - 그들이 읽고 실행하게 하십시오.
그건 그렇고, 여기 배열에 대한 참조에 대해 생각했습니다 ...
Renat , 저는 제안합니다.
표준 라이브러리 가 있으므로 다음 프로토타입을 사용하여 OnCalculate() 함수의 변형을 추가하면 안 됩니다.
정수 OnCalculate ( const int Rates_total, // 입력 시계열의 크기
상수 int prev_calculated, // 이전 호출에서 처리된 막대
const СiTime* ptTime, // 시간
const CiOpen * poOpen, // 열기
const CiHigh* phHigh, // 높음
const CiLow* plLow, // 낮음
const CiClose* pcClose, // 닫기
const CiTickVolume* ptvT ickVolume, // 틱 볼륨
const CiRealVolume* prvRealVolume , // 실제 볼륨
const CiSpread* psS pread // 확산
);
?
제 생각에는 MetaTrader에서 매우 작은 변경이 필요하지만 다른 한편으로 함수는 복사하지 않고 핸들러 클래스에 전달할 수 있는 배열에 대한 포인터만 즉시 제공합니다. 그리고 표준 라이브러리 자체에 대한 아이디어가 대중화되고 있습니다.
실제 대규모 프로젝트 (~ 20,000줄의 소스 코드) 예제에서 이전 컴파일러와 새 컴파일러의 성능을 비교한 첫 번째 결과를 얻었습니다.
이전 버전의 컴파일러에서 컴파일된 프로그램의 실행 시간 결과(4회 실행):
새 버전의 컴파일러에서 컴파일된 프로그램의 실행 시간 결과(4회 실행):
*프로그램의 두 번째 및 후속 실행은 웜 캐시에서 수행되었습니다. 보시다시피 웜 캐시는 성능을 15-30% 향상시킵니다.
보시다시피 새 컴파일러의 작업 결과가 더 좋습니다. 20,000개 이상의 거래 및 주문을 구문 분석하는 데 첫 번째 경우에는 ~6.4초, 두 번째 경우에는 ~5.4초가 소요되었습니다. 15-20% 성능 향상.
성능 향상은 더 클 수 있지만 대부분의 시간은 시스템 함수 호출에 의해 차지됩니다.
새 컴파일러는 소스 코드의 총 볼륨이 20,000라인 이상인 프로젝트 에서 오류를 발견하지 못했습니다. 이 프로젝트가 이전 버전의 컴파일러를 위해 생성되었다는 점을 고려하면 이는 놀라운 결과입니다.
그러나 새 컴파일러는 파일 경로의 잘못된 표시(슬래시 이스케이프 요구 사항)와 관련된 몇 가지 경고 메시지를 발행했습니다.
이것은 몇 가지 사소한 변경으로 쉽게 충족될 수 있는 상당히 공정한 요구 사항입니다.
따라서 MQL5의 대규모 프로젝트도 새 컴파일러를 사용할 준비가 되었으며 전문 개발자에게는 이 컴파일러로의 전환이 어렵지 않을 것이라고 결론을 내릴 수 있습니다.
...
" 코드 생성 오류 1 1 "이 나타납니다.
...
수학 및 자체 계산의 주요 이점.
시스템 기능을 최소한으로 호출하여 고유한 환경을 만들 수 있기 때문에 여전히 좋습니다.
(우리는 환경을 클래스에 한 번 복사하고 직접 작업합니다)
뭐 그런 변태라면 당연히 DLL은 필수 기능이지...
하지만 개인적으로 이러한 작업을 위해 DLL이 실제로 필요하지 않다고 결정했습니다. 지금은 한 DC에서 견적을 받아 다른 DC뿐만 아니라 MetaTrader가 없는 거래를 위한 신호를 보낼 고문에 대해 생각하고 있습니다. (그런데 DukaKopy, 나는 MetaQuotes가 이 유서 깊은 중개인을 다룰 것인지 궁금합니다.).
DLL의 방향으로 생각했습니다. 하지만 공유 파일이 훨씬 안전하고 합리적이라고 판단했습니다. MetaTrader가 파일에 신호를 쓰도록 합니다. 그리고 또 다른 MetaTrader(또는 JForex, 또는 다른 사람) - 그들이 읽고 실행하게 하십시오.
명명된 파이프 옵션이 있지만 여기에는 중간 서버가 필요합니다.
포럼에 예제가 있습니다. 작동한다고 말할 수도 있습니다.
예를 들어, 터미널 간 통신.
명명된 파이프 옵션이 있지만 여기에는 중간 서버가 필요합니다.
포럼에 예제가 있습니다. 작동한다고 말할 수도 있습니다.
명명된 파이프가 필요하지 않습니다! SQL 지원을 추가하기를 기대합니다. 테이블을 통한 데이터 교환. SQL은 다중 스레드, 고부하 시스템에 대한 기본 제공 지원입니다.