사전 정의된 정적 데이터. 컴파일 타임에 프로그램에 재봉되어 더 이상 변경되지 않습니다. 그들은 일부 개인 메모리 영역에 있습니다. 예를 들어, 여기에는 char[1024] 형식의 정적 배열이 포함됩니다.
포인터를 통해 수동으로 관리되는 데이터. 여기에는 클래스의 인스턴스가 포함되지만 CFoo* bar와 같은 포인터를 통해 정의됩니다. 여기서 bar는 CFoo 클래스의 인스턴스입니다. 이러한 인스턴스는 POINTER_DYNAMIC 유형이 됩니다. 이러한 유형의 저장소는 대부분의 경우 필요하지 않지만 가장 문제가 많습니다.
프로그램이 실행 중인 mql 가상 머신의 가비지 수집기가 관리하는 데이터입니다. 여기에는 클래스 인스턴스가 포함됩니다. 이 유형의 개체에 대한 포인터는 POINTER_AUTOMATIC 형식입니다. 그리고 이러한 개체 자체는 이 가상 머신의 힙 또는 개인 섹션에 있습니다. 구체적으로 데이터에 의존하는 정도, 크기가 표시되며 개발자가 보유하는 방법. 이 정보를 사용할 수 없습니다. 이러한 데이터에는 사용자 정의 클래스가 포함됩니다. 포인터가 없는 모든 클래스 인스턴스 정의는 이 스토리지 유형을 정의합니다. 예를 들어 CFoo bar는 해제할 필요가 없는 CFoo 클래스의 bar 인스턴스를 정의합니다. 모든 릴리스 작업은 가상 머신에서 수행됩니다. 삭제 연산자를 사용할 필요가 없으므로 누출된 개체 문제에 직면하게 됩니다.
스택에 있는 데이터입니다. 여기에는 우선 함수의 지역 변수가 포함됩니다. 저것들. 함수 내부에 int a = 5라고 쓰면 스택의 맨 위가 4바이트 위로 이동하여 필요한 양의 메모리를 할당합니다. 아마도 MQL에서 구조는 스택에 저장되는 유형이기도 합니다(솔직히 확인하지 않았습니다). 이러한 데이터는 공간을 거의 차지하지 않으며 중첩된 함수 호출 체인이 있어도 스택 전체에 필요한 메모리는 힙보다 훨씬 적습니다. 이 유형의 저장소는 자동으로 사용되므로 생각할 필요가 없습니다.
스택이 함수와 해당 지역 변수에 맡겨진 경우 작업할 세 가지 유형이 있습니다. 개인적으로 나는 자동 수명을 가진 데이터가 이전 두 유형의 장점을 잘 결합하지만 단점이 없다고 생각합니다(이것은 제 생각일 뿐입니다). 자동 포인터로 정의된 데이터는 정적 데이터만큼 예측 가능하고 안전하지만 수동으로 제어되는 동적 데이터만큼 유연합니다. 예측 가능성이란 추가 작업이 필요하지 않은 시나리오를 의미합니다. 깨진 포인터를 확인하고 다른 사람이 이전에 이 데이터를 이미 삭제했는지 궁금합니다. 유연성이란 일반 포인터와 마찬가지로 자동 포인터가 참조하는 데이터로 작업하고 이 포인터를 일부 함수에 전달하거나 배열과 관련하여 크기를 조정할 수 있는 시나리오를 의미합니다.
이를 설명하기 위해 Ihor Herasko가 제안한 원본 코드와 POINTER_AUTOMATIC 형식에 대해 제공한 동일한 코드를 비교할 수 있습니다. 불필요한 검사 및 초기화가 없으며 삭제 연산자를 60,000,000번 호출하지 않습니다. 이 모든 것이 에너지, 시간, 그리고 중요하지 않은 자원을 실질적으로 절약합니다. 당신이 그것을 알아 내면 포인터로 작업 할 필요가 거의 없습니다. 이러한 알고리즘을 작성하는 것은 항상 가능하며 이 작업은 최소로 또는 0으로 줄어들 것입니다. 예를 들어, 내 코드에서는 개체를 수동으로 관리하지 않습니다. 단지 이것이 필요하지 않을 뿐입니다. 정적 배열의 경우, 예를 들어 프로그램에 필요한 데이터를 꿰매기 위해 때때로 그것들을 사용해야 하지만, 이것들은 너무 구체적인 것들이어서 일반 사용자에게는 필요하지 않다고 생각합니다. CArrayObj 유형의 기성품 컬렉션 또는 자체 컬렉션을 사용하는 것이 가장 좋습니다. 이제 템플릿과 MQL 기능을 사용하면 정적 배열보다 훨씬 더 나은 매우 유연한 것을 만들 수 있습니다.
MQL 프로그램은 특정 가상 머신에서 실행됩니다. Renat는 이것에 대해 아무렇지도 않게 그리고 한 번 이상 썼습니다.
자동으로 할당 해제되는 클래스의 인스턴스를 정의할 수 있습니다. 따라서 이러한 인스턴스를 추적하고 필요한 경우 해제하는 몇 가지 메커니즘이 있습니다. 가비지 컬렉터가 아니면 무엇입니까?
적절하게 할당 해제되지 않은 포인터를 통해 초기화된 모든 인스턴스는 프로그램이 종료될 때 누수된 개체로 표시됩니다. 해당 번호와 낭비된 메모리의 총량이 인쇄됩니다. 메모리 누수가 있는 프로그램은 시장에서 검증조차 통과하지 못합니다. 따라서 수동으로 선택한 모든 개체를 포함하여 모든 개체가 고려되고 알려지며 시스템이 인식합니다. 이것은 가비지 수집기가 해결하는 고전적인 작업 중 하나입니다.
확인. 이해가 안 됩니다. 이해했나요? 정확히 이해가 되셨나요? 정확히 정확히?
논쟁은 다음 진술로 요약됩니다.
...
일반적인 분쟁이 아니라 한 게시물에 대한 상황에 대한 이야기였고, 문제가 무엇인지 설명을 드렸습니다. 좋아요, 충돌은 발생하지 않았습니다.
선언된 배열 double x[268435448];
OnStart() 함수 의 동일한 배열입니다.
또한 깊이가 LONG_MAX인 재귀 호출을 했습니다.
괜찮아요.
정적 배열을 사용하지 않습니까?
크기가 큰. 배열 크기가 작고 일정하며 미리 알려진 경우 정적 배열이 더 좋고 더 빠를 것입니다.
크기가 큰. 배열의 크기가 작고 일정하며 미리 알려진 경우 정적 배열이 더 좋고 더 빠를 것입니다.
정적 변수/배열 및 해당 크기 목록을 가져오는 방법을 알고 싶습니다. 아마도 여기에서 수행되는 것처럼 코드 분석기가 필요합니다.
ZY 아마도 정적 문자열 배열과 이중 배열 - 완전히 다른 것입니다.
ZY 아마도 정적 문자열 배열과 이중 배열 - 완전히 다른 것입니다.
string은 본질적으로 포인터와 크기의 int로 구성된 내부 클래스입니다. double의 경우 배열은 조건부로 1.5배 적은 공간을 차지합니다.
수백만 개의 요소가 포함된 정적 배열이 없는 한 많은 고민을 하는 것이 합리적이지 않다고 생각합니다.
정적 배열을 사용하지 않습니까?
MQL에는 기본적으로 네 가지 유형의 데이터가 있습니다.
스택이 함수와 해당 지역 변수에 맡겨진 경우 작업할 세 가지 유형이 있습니다. 개인적으로 나는 자동 수명을 가진 데이터가 이전 두 유형의 장점을 잘 결합하지만 단점이 없다고 생각합니다(이것은 제 생각일 뿐입니다). 자동 포인터로 정의된 데이터는 정적 데이터만큼 예측 가능하고 안전하지만 수동으로 제어되는 동적 데이터만큼 유연합니다. 예측 가능성이란 추가 작업이 필요하지 않은 시나리오를 의미합니다. 깨진 포인터를 확인하고 다른 사람이 이전에 이 데이터를 이미 삭제했는지 궁금합니다. 유연성이란 일반 포인터와 마찬가지로 자동 포인터가 참조하는 데이터로 작업하고 이 포인터를 일부 함수에 전달하거나 배열과 관련하여 크기를 조정할 수 있는 시나리오를 의미합니다.
이를 설명하기 위해 Ihor Herasko가 제안한 원본 코드와 POINTER_AUTOMATIC 형식에 대해 제공한 동일한 코드를 비교할 수 있습니다. 불필요한 검사 및 초기화가 없으며 삭제 연산자를 60,000,000번 호출하지 않습니다. 이 모든 것이 에너지, 시간, 그리고 중요하지 않은 자원을 실질적으로 절약합니다. 당신이 그것을 알아 내면 포인터로 작업 할 필요가 거의 없습니다. 이러한 알고리즘을 작성하는 것은 항상 가능하며 이 작업은 최소로 또는 0으로 줄어들 것입니다. 예를 들어, 내 코드에서는 개체를 수동으로 관리하지 않습니다. 단지 이것이 필요하지 않을 뿐입니다. 정적 배열의 경우, 예를 들어 프로그램에 필요한 데이터를 꿰매기 위해 때때로 그것들을 사용해야 하지만, 이것들은 너무 구체적인 것들이어서 일반 사용자에게는 필요하지 않다고 생각합니다. CArrayObj 유형의 기성품 컬렉션 또는 자체 컬렉션을 사용하는 것이 가장 좋습니다. 이제 템플릿과 MQL 기능을 사용하면 정적 배열보다 훨씬 더 나은 매우 유연한 것을 만들 수 있습니다.
Vasiliy Sokolov # :
사전 정의된 정적 데이터. 컴파일 타임에 프로그램에 재봉되어 더 이상 변경되지 않습니다. 그들은 개인 메모리의 특정 영역에 있습니다. 예를 들어, 여기에는 char[1024] 형식의 정적 배열이 포함됩니다.
배열이 초기화되지 않은 경우
왜 EX5에서 꿰매나요?
배열이 초기화되지 않은 경우
왜 EX5에서 꿰매나요?
네 맞습니다, 초기화되지 않은 것들은 당연히 재봉되지 않습니다. 초기화된 것들이 재봉됩니다. 그러나 두 유형의 크기는 컴파일 시간에 결정되며 더 이상 변경되지 않습니다. 저것들. 정적 배열은 조건부로 두 그룹으로 나눌 수 있습니다.
emkule에는 가비지 수집기가 없습니다.
공식적으로 그렇습니다. 비공식적으로 많은 것들이 그가 여전히 존재함을 나타냅니다.