기고글 토론 "MQL5 Cookbook: 빠른 데이터 액세스를 위한 연관 배열 또는 사전 구현" - 페이지 2

 
매우 훌륭하고 흥미로운 기사입니다. 감사합니다.
[삭제]  
좋은 기사와 초보자 단계에 대한 도움말
 

죄송합니다!

저는 이제 막 목록과 객체 생성에 대해 배우고 있습니다.

코드를 테스트하고 파헤치기 시작했을 때 사소한 오류를 발견했지만 제가 틀렸을 수도 있습니다.

라이브러리와 표준 라이브러리를 비교하여 속도를 측정 할 때 누가 더 빠른지 측정 할 때 설명에서 한 가지를 말하지만 그래프에는 다른 것을 표시합니다. 눈치채지 못했거나 제가 그래프를 잘못 읽었나요?

P.P. 4.3.

 
BmC:

죄송합니다!

저는 이제 막 목록과 객체 생성에 대해 배우고 있습니다.

코드를 테스트하고 파헤치기 시작했을 때 사소한 오류를 발견했지만 제가 틀렸을 수도 있습니다.

라이브러리와 표준 라이브러리를 비교하여 속도를 측정 할 때 누가 더 빠른지 측정 할 때 설명에서 한 가지를 말하지만 그래프에는 다른 것을 표시합니다. 눈치채지 못했거나 제가 그래프를 잘못 읽었나요?

P.P. 4.3.

처음에 나는 그것이 실제로 실수라고 썼지 만 그래프를 더주의 깊게 살펴본 결과 아니요, 모든 것이 정확합니다. Y축은 시간을 나타내며, 시간이 길수록 항목 추가가 느리게 작동합니다. 이 차트를 보면 CArrayObj에 백만 개의 항목을 추가하는 데 5초가 걸리는 반면 CDictionary에 같은 수의 항목을 추가하는 데 1초가 걸리는 것을 알 수 있습니다. 즉, 특히 요소를 순차적으로 대량으로 추가하는 작업에서 CDictionary의 메모리 재할당 모델이 CArrayObj의 표준 재할당 모델에 비해 우위를 점하고 있음을 보여줍니다.

 
Vasiliy Sokolov:

처음에는 이것이 정말 실수라고 썼지만 그래프를 더 자세히 살펴보니 아니요, 모든 것이 정확합니다. Y축은 시간을 나타내며, 시간이 길수록 항목을 추가하는 데 걸리는 시간이 느려집니다. 이 차트를 보면 CArrayObj에 백만 개의 항목을 추가하는 데 5초가 걸리는 반면 CDictionary에 같은 수의 항목을 추가하는 데는 1초가 걸리는 것을 알 수 있습니다. 즉, 특히 대량의 항목을 순차적으로 추가하는 작업에서 CDictionary의 메모리 재할당 모델이 CArrayObj의 표준 재할당 모델에 비해 우위를 점하고 있음을 보여줍니다.

아니요, 여전히 실수입니다. 그러나 저에게는 중요하지 않지만 다른 독자들에게는 그렇습니다. 처음부터 저처럼 이해할 것입니다. 그것은 먼 오해를 불러일으키기 때문에 매우 정확하게 작성되어야 합니다. ))))

quote: TEST_ARRAY 매크로를 사용합니다. 이 매크로가 정의되어 있으면 테스트는 CArrayObj에서, 정의되어 있지 않으면 CDictionary에서 작업을 수행합니다. 새 요소를 추가하는 첫 번째 테스트는 CDictionary보다 승리하며, 이 특별한 경우에는 메모리 재할당 모델이 더 좋습니다:

MUST HAVE: TEST_ARRAY 매크로를 사용합니다. 이 매크로가 "NOT"으로 정의되어 있으면 테스트는 CArrayObj에서 연산을 수행하고, "YES"로 정의되어 있으면 CDictionary에서 연산을 수행합니다. 새 요소 추가에 대한 첫 번째 테스트는 CDictionary보다 메모리 재할당 모델이 이 특별한 경우에서 더 우수했습니다:

전체 오류는 처음부터 코드에서 직접 CDictionary를 통해 목록을 채우고 정의되지 않은 경우 매크로 TEST_ARRAY가 CArrayObj가 여기에서 오류가 발생한 곳입니다. 하나의 머티리얼에 대한 작업의 피로도 때문이죠.

하지만 시간이 많이 걸리는 큰 문제입니다. 포인터와 객체 생성을 이해하는 데 포인터와 객체 생성에 대해 들어가기가 매우 어려웠습니다. 그리고 단기간에 필요합니다......

 

BmC:

포인터와 객체 생성에 대해 많은 도움을 받았습니다. 를 이해하는 데 많은 도움을 받았습니다.

MQL4와 MQL5에는 포인터가 없고 설명자만 있는데, 이는 완전히 다른 구성입니다.
 
Alexey Volchanskiy:
В MQL4 и MQL5 нет указателей, есть дескрипторы, это совсем другой компот.
Alexey Volchanskiy
:

MQL4와 MQL5에는 포인터가 없고 설명자가 있으며, 완전히 다른 컴포트라고 할 수 있습니다.

당신은 영리 해지려고 노력하고 있습니까, 아니면 그냥 등급을 받으려고 노력하고 있습니까? 기사와 제가 쓴 글을 읽을 시간이 없다면 더 이상 그렇게하지 말고 MetaQuotes Software Corp. 제작자에게 그들이 가지고 있거나 있어야하는 것을 여기에 똑똑한 사람들에게 쓰지 말고 여기에 쓰라고 요청합니다. 당신처럼 미래에 그것을 원하는 사람들을 위해 : www.mql5.com/ru/docs/basis/types/object_pointers. 

그런 어리석은 진술에 대해서만 등급이 있어야합니다. 그렇다면 넌센스를 3000 번 쓰는 것은 무엇입니까? 할 일이 없다면 MQL 참조를 다시 읽으십시오. 어리석은 진술에 대한 평가가 너무 많이 필요하다면 어리석은 아이디어의 제작자에게 편지를 쓰면 거기에서 돈을받습니다.

내가 이것으로 말하고 싶은 것을 이해하지 못했다면 예를 들어, 나는 여전히 제작자에게 어리석은 아이디어를 쓸 수 있음을 알려줍니다: " class="linkator">"객체 설명자" 장으로 바꾸어 달라고 요청합니다."

그런 다음 그 이유를 설명합니다. "나는 너무 멍청하고 내 모든 멍청한 것들이 진실하고 합리적인 진술이 되기를 원하니 나를 '창조자'로 구해 주세요.

제가 "창조자"라면 "일곱 꽃이 핀 꽃"의 꽃을 얻으라고 조언하고 싶습니다. 하지만 이미 세 개의 진술을 작성했으니 상관없습니다. 3093+3=3096. 이제 더 이상 여기에 글을 쓰지 않도록 도와 주셨습니다.

나는 오랫동안 포럼에 있었고 당신의 진술은 항상 어리 석고 일정하다는 것을 알았습니다. 주제에 대한 당신은 항상 스 니펫으로 작성하고 항상 모든 사람을 수정하고, 여기에서 그런 어리석은 진술을 수정합니다. 나는 또한 지식을 보충하기 위해 포럼을 오르고 3000 등급을 가진 "전문가"가 그에게 듣는 것과 같은 사용자 초보자이기 때문에 나는 당신이 너무 화가 났기 때문입니다. 그리고 그는 자신을 위해 등급을 매기려는 목표를 설정 한 바보 일뿐입니다. 그는 자신의 진술이 지점의 독자를 다른 방향으로 지시한다고 생각조차하지 않습니다.

다시 한 번 사과드립니다. 다시 한 번 제 답글에 걸리면 차단을 요청할 것이며, 어리석게 얻은 평점을 잃게 될 것입니다. 특히 운영자에게 당신의 어리석음을 증명하기 위해 항상 주제에 대한 답변이 짧고 어리석다는 것을 증명합니다.

[삭제]  

벌써 9월인데 이 클래스는 표준 라이브러리에 없습니다 :)

그건 그렇고, 클래스 자체의 코드에 대한 질문입니다. 코드 마지막에 정의한 이유가 뭔가요?

#define  FOREACH_DICT(dict) for(CObject* node = (dict).GetFirstNode(); node != NULL; node = (dict).GetNextNode())
예제 어디에도 사용되지 않았기 때문에...
 
Konstantin Karpov:

벌써 9월인데 이 클래스는 표준 라이브러리에 없습니다 :)

그건 그렇고, 클래스 자체의 코드에 대한 질문입니다. 코드 마지막에 정의한 이유가 뭔가요?

예제 어디에도 사용되지 않았기 때문에...
사용되었습니다. 5.3 단락: "사전에서 요소를 열거하는 방법". 사전 열거는 오히려 목록 열거와 비슷하기 때문에 열거 연산이 표준이 아니며 for의 내용이 고전적인 배열 열거의 내용과 다릅니다. 저희와 사용자의 편의를 도모하고 노드 열거를 힘들게 기억하지 않기 위해 이 매크로가 도입되었습니다.
 
Mr EA에게 전화하기