다음 형식의 문자열로 작업하기 위해 표준 라이브러리 에 함수를 추가하는 것이 좋을 것입니다. 문자열을 "시작", "끝"으로 제한되는 모듈로 구문 분석하고 문자열 배열에 씁니다. 예: int count=(문자열, 배열,"<h1>","</h1>",flag); .여기서 string은 들어오는 문자열, array는 나가는 문자열 배열, "<h1>"은 문자열의 모듈 시작 부분, "</h1>"은 문자열의 모듈 끝 부분입니다. 플래그 - 모듈 구분 기호가 어레이의 출력 라인에 포함되어야 하는지 여부를 나타냅니다. count - 발견된 모듈의 수입니다.
이 경우 int count=(string, array,"<h1>","</h1>",flag); - 문자열에 있는 모든 헤더의 질량을 생성합니다.
나는 보고한다. 그리고 섹션. 그리고 마스터했습니다. 필요한 경우 정리할 수 있습니다. 나는 여전히 MQL을 마스터해야 하므로 언어에 대한 거의 모든 질문은 바보가 될 위험이 있습니다.
다른 것을 잘못 이해했습니다. ""차트의 최대 막대" 매개변수는 차트, 지표 및 mql5 프로그램에 사용할 수 있는 HC 형식의 막대 수를 제한합니다. 이 제한은 모든 기간의 데이터에 적용되며 주로 저장하기 위한 것입니다. 자원.
이 매개변수의 큰 값을 설정할 때 더 낮은 기간에 대한 가격 데이터의 충분히 깊은 기록이 있는 경우 시계열 및 표시기 버퍼를 저장하기 위한 메모리 소비가 수백 메가바이트에 달할 수 있고 RAM 제한에 도달할 수 있음을 기억해야 합니다. 클라이언트 터미널 프로그램(32비트 MS Windows 응용 프로그램의 경우 2GB)."
이번화에서는 무슨 일이 일어나고 있는지 잘 이해가 되지 않았을 수도 있지만, 동시에 MQL 프로그램에 대한 질문은 하지 않겠다는 점을 다시 한번 강조하지만, 직접 수동으로 작업할 때 단말이 자동 이력 요청을 하는 것에 대해서는 차트를 보면 위의 자원 절약 동기가 이상해 보입니다. 귀하의 코드가 닫혀서 모든 것이 어떻게 작동하는지 판단할 수 없습니다. 각 촛대가 속성과 속성의 병든 클러스터를 가진 병약한 개체인지 또는 시장의 구조적 이미지에 대한 단순화된 그래픽 그리기/다시 그리기가 있는지 모르겠습니다. 누락된 역사를 펌핑하는 주제를 생략하고 이미 사용할 수 있는 것으로 제한하면 드로잉 접근 방식의 합리성에 대한 질문이 발생합니다. 설정에서 차트에 막대의 최대수를 일정하고 크게 설정해도 차트의 막대를 바늘로 압축해도 모니터를 매우 고해상도로 설정해도 믿겨지지 않습니다 막대가 기록 DBMS에서 화면으로 올바르게 로드되면 보이는 전체 그림이 RAM을 죽입니다. LIFO 원리를 사용하고 있습니까? 차트의 최대 막대 수는 무한대로 클 수 있지만 화면 뒤에 있는 것(오른쪽에 있는 것, 왼쪽에 있는 것)은 메모리에 전혀 남아 있지 않아야 하며 스크롤할 때 로드되어야 합니다. 화면을 떠난 RAM을 언로드하는 RAM은 즉각적이어야 합니다. 여기서 우리는 Net으로 작업하지 않고 로컬에서 사용 가능한 기록으로만 작업하기 때문입니다. 어떤 종류의 끔찍한 2GB 제한에 대해 이야기할 수 있습니까?
structMqlRates
{
datetime time; // время начала периодаdouble open; // цена открытияdouble high; // наивысшая цена за периодdouble low; // наименьшая цена за периодdouble close; // цена закрытияlong tick_volume; // тиковый объемint spread; // спредlong volume; // объем
};
작업 데이터베이스의 양을 추정하려면 /bases/servername/symbol/ 디렉토리를 살펴봐야 합니다. 예를 들어 EURUSD의 경우 다음을 볼 수 있습니다.
이 디렉토리에는 거래 서버에서 제공한 원래 압축된 분 컨테이너가 포함되어 있습니다. 평균적으로 1년 분은 약 15mb 정도가 소요되는 것을 알 수 있습니다. 이것은 트래픽을 최소화하기 위한 매우 구체적인 압축 형식입니다.
필요에 따라 생성된 압축 해제된 작업 데이터베이스는 캐시 디렉터리에 저장됩니다.
여기에서 1993년 이후의 분(사실 1999년까지 분 대신 일이 있음)이 압축 해제되고 바로 사용할 수 있는 형식으로 231MB를 차지하는 것을 볼 수 있습니다. 동시에 근처 시계는 4MB만 차지합니다.
52바이트에 4,400,000바를 곱하면 약 230MB의 값을 얻게 됩니다. 하나의 작업 버퍼(이중)가 있는 간단한 이동 평균 표시기를 이러한 기록에 적용하려면 4,400,000 * 8 = 35MB의 메모리가 필요합니다.
거래자가 터미널 설정에서 "창당 최대 막대"를 설정할 때 그는 "작업을 위해 지정된 수의 막대를 메모리에 로드하지 마십시오"라고 명시적으로 말합니다. 분의 전체 기록이 로드되면(M1 차트에서 작업이 진행 중임) 여러 무거운 다중 버퍼 표시기가 중첩되고 전문가가 사용되므로 메모리 비용이 상당할 수 있습니다. 그리고 당신은 "나는 하나의 창으로 작업하고 있습니다. 나는 500개의 막대를 보고 나머지는 언로드할 수 있습니다."라고 셀 수 없습니다. 지표, 전문가 등을 언로드하는 것은 불가능합니다. 이 데이터에 대해 살고 작업합니다.
우리는 데이터와 지표가 항상 단수로 저장되는 매우 효율적인 캐싱 모델을 구현했습니다. 즉, EURUSD:M1에서 5개의 창을 열 때 데이터가 포함된 5개의 버퍼를 생성할 필요가 없으며 매개변수가 절대적으로 동일한 여러 지표에는 하나의 복사본만 있습니다. 지표나 차트를 장기간 사용하지 않으면 데이터가 자동으로 해제되고 필요에 따라 다시 올립니다.
또한 64비트 버전의 클라이언트 터미널을 보유하고 있어 제약 없이 방대한 이력을 처리할 수 있습니다. 이 버전은 64비트 환경에서 MQL5 테스트가 완료되는 대로 출시될 예정입니다.
프로그램이 끝날 때 클래스를 설명할 수 없고 처음에만 클래스를 설명하는 것이 매우 편리합니다.
워드에서처럼 편집창을 두 개의 독립된 창으로 나누는 슬라이더를 편집기에서 만드는 것이 좋을 것입니다. 프로그램의 두 부분을 동시에 복사, 작성 및 시청하는 것이 편리할 것입니다.
그건...
유일한 예외(반드시 그런 것은 아님)는 주말입니다. 건너뛸 수 있지만 다른 기기에 대해 동기적으로 다시 보장됩니다.
외환은 실제로 주말에 작동한다는 것을 알고 있습니까?
대부분의 브로커는 작동하지 않습니다
---
일부는 주말에 견적을 제공하고 주문 작업을 허용합니다.
매우 편리한
주말에는 스프레드를 열 수 있습니다. 유동성이 없습니다.
그러나 기회를 바꾸기 위해 열린 뒤에 숨는 것은
다음 형식의 문자열로 작업하기 위해 표준 라이브러리 에 함수를 추가하는 것이 좋을 것입니다. 문자열을 "시작", "끝"으로 제한되는 모듈로 구문 분석하고 문자열 배열에 씁니다. 예: int count=(문자열, 배열,"<h1>","</h1>",flag); .여기서 string은 들어오는 문자열, array는 나가는 문자열 배열, "<h1>"은 문자열의 모듈 시작 부분, "</h1>"은 문자열의 모듈 끝 부분입니다. 플래그 - 모듈 구분 기호가 어레이의 출력 라인에 포함되어야 하는지 여부를 나타냅니다. count - 발견된 모듈의 수입니다.
이 경우 int count=(string, array,"<h1>","</h1>",flag); - 문자열에 있는 모든 헤더의 질량을 생성합니다.
이는 기존 도구를 사용하여 구현할 수도 있습니다 . MQL4로 HTML 구문 분석 문서를 읽어보세요.
글쎄, 사용 가능한 수단으로이 단계를 단계적으로 수행하는 것이 가능하다는 것이 분명합니다. 그러나 한 번에 모든 것을 수행하는 하나의 기성 기능을 갖는 것이 두 페이지의 코드보다 낫습니다....
편집기에서 프로그램 코드의 일부 블록을 숨기거나 여는 기능이 있으면 유용할 것입니다. 예를 들어, 섹션 "함수", "정의", "클래스"... 또는 프로그램 코드의 중첩 섹션을 숨기거나 열 수 있습니다(예: 문 for , if ...
데이터 액세스 구성 섹션을 읽고 기록을 올바르게 쿼리하는 방법을 알려줍니다.
나는 보고한다. 그리고 섹션. 그리고 마스터했습니다. 필요한 경우 정리할 수 있습니다. 나는 여전히 MQL을 마스터해야 하므로 언어에 대한 거의 모든 질문은 바보가 될 위험이 있습니다.
다른 것을 잘못 이해했습니다. ""차트의 최대 막대" 매개변수는 차트, 지표 및 mql5 프로그램에 사용할 수 있는 HC 형식의 막대 수를 제한합니다. 이 제한은 모든 기간의 데이터에 적용되며 주로 저장하기 위한 것입니다. 자원.
이 매개변수의 큰 값을 설정할 때 더 낮은 기간에 대한 가격 데이터의 충분히 깊은 기록이 있는 경우 시계열 및 표시기 버퍼를 저장하기 위한 메모리 소비가 수백 메가바이트에 달할 수 있고 RAM 제한에 도달할 수 있음을 기억해야 합니다. 클라이언트 터미널 프로그램(32비트 MS Windows 응용 프로그램의 경우 2GB)."
이번화에서는 무슨 일이 일어나고 있는지 잘 이해가 되지 않았을 수도 있지만, 동시에 MQL 프로그램에 대한 질문은 하지 않겠다는 점을 다시 한번 강조하지만, 직접 수동으로 작업할 때 단말이 자동 이력 요청을 하는 것에 대해서는 차트를 보면 위의 자원 절약 동기가 이상해 보입니다. 귀하의 코드가 닫혀서 모든 것이 어떻게 작동하는지 판단할 수 없습니다. 각 촛대가 속성과 속성의 병든 클러스터를 가진 병약한 개체인지 또는 시장의 구조적 이미지에 대한 단순화된 그래픽 그리기/다시 그리기가 있는지 모르겠습니다. 누락된 역사를 펌핑하는 주제를 생략하고 이미 사용할 수 있는 것으로 제한하면 드로잉 접근 방식의 합리성에 대한 질문이 발생합니다. 설정에서 차트에 막대의 최대수를 일정하고 크게 설정해도 차트의 막대를 바늘로 압축해도 모니터를 매우 고해상도로 설정해도 믿겨지지 않습니다 막대가 기록 DBMS에서 화면으로 올바르게 로드되면 보이는 전체 그림이 RAM을 죽입니다. LIFO 원리를 사용하고 있습니까? 차트의 최대 막대 수는 무한대로 클 수 있지만 화면 뒤에 있는 것(오른쪽에 있는 것, 왼쪽에 있는 것)은 메모리에 전혀 남아 있지 않아야 하며 스크롤할 때 로드되어야 합니다. 화면을 떠난 RAM을 언로드하는 RAM은 즉각적이어야 합니다. 여기서 우리는 Net으로 작업하지 않고 로컬에서 사용 가능한 기록으로만 작업하기 때문입니다. 어떤 종류의 끔찍한 2GB 제한에 대해 이야기할 수 있습니까?
...제가 너무 주제를 벗어난 것 같으니 미리 양해를 구하십시오.
각 가격 막대는 52바이트 크기의 MqlRates 구조(다른 특성 없음)로 설명됩니다.
작업 데이터베이스의 양을 추정하려면 /bases/servername/symbol/ 디렉토리를 살펴봐야 합니다. 예를 들어 EURUSD의 경우 다음을 볼 수 있습니다.
이 디렉토리에는 거래 서버에서 제공한 원래 압축된 분 컨테이너가 포함되어 있습니다. 평균적으로 1년 분은 약 15mb 정도가 소요되는 것을 알 수 있습니다. 이것은 트래픽을 최소화하기 위한 매우 구체적인 압축 형식입니다.
필요에 따라 생성된 압축 해제된 작업 데이터베이스는 캐시 디렉터리에 저장됩니다.
여기에서 1993년 이후의 분(사실 1999년까지 분 대신 일이 있음)이 압축 해제되고 바로 사용할 수 있는 형식으로 231MB를 차지하는 것을 볼 수 있습니다. 동시에 근처 시계는 4MB만 차지합니다.
52바이트에 4,400,000바를 곱하면 약 230MB의 값을 얻게 됩니다. 하나의 작업 버퍼(이중)가 있는 간단한 이동 평균 표시기를 이러한 기록에 적용하려면 4,400,000 * 8 = 35MB의 메모리가 필요합니다.
거래자가 터미널 설정에서 "창당 최대 막대"를 설정할 때 그는 "작업을 위해 지정된 수의 막대를 메모리에 로드하지 마십시오"라고 명시적으로 말합니다. 분의 전체 기록이 로드되면(M1 차트에서 작업이 진행 중임) 여러 무거운 다중 버퍼 표시기가 중첩되고 전문가가 사용되므로 메모리 비용이 상당할 수 있습니다. 그리고 당신은 "나는 하나의 창으로 작업하고 있습니다. 나는 500개의 막대를 보고 나머지는 언로드할 수 있습니다."라고 셀 수 없습니다. 지표, 전문가 등을 언로드하는 것은 불가능합니다. 이 데이터에 대해 살고 작업합니다.
우리는 데이터와 지표가 항상 단수로 저장되는 매우 효율적인 캐싱 모델을 구현했습니다. 즉, EURUSD:M1에서 5개의 창을 열 때 데이터가 포함된 5개의 버퍼를 생성할 필요가 없으며 매개변수가 절대적으로 동일한 여러 지표에는 하나의 복사본만 있습니다. 지표나 차트를 장기간 사용하지 않으면 데이터가 자동으로 해제되고 필요에 따라 다시 올립니다.
또한 64비트 버전의 클라이언트 터미널을 보유하고 있어 제약 없이 방대한 이력을 처리할 수 있습니다. 이 버전은 64비트 환경에서 MQL5 테스트가 완료되는 대로 출시될 예정입니다.