자신과 자신의 프로그램을 존중하는 프로그래머는 모든 것이 순조롭게 진행되도록 내버려 두지 않을 것입니다. MQL4에서 #property strict를 사용하지 않으면 인덱스 20에서 크기가 10인 배열을 참조할 수 있습니다. 그리고 아무 일도 일어나지 않을 것입니다. 프로그램은 계속 작동하지만 프로그래머가 거기에서 무엇을 가져와 사용할 것입니까? 그의 어깨에. 그가 똑똑하다면 그는 배열 외부의 값을 얻지 않도록 모든 것을 확실히 확인하고 통제 할 것이지만 그가 "실수"라면 그는 그러한 통제에 신경 쓰지 않으며 "주요한 것은 그것은 작동하지만 어떻게 - 글쎄, 어떻게 - 스레드 ...". 대부분의 경우, 아무 것도 귀찮게하지 않고 울부 짖는 것은 그러한 사용자였습니다. 이제는 "나쁘고 사악하고 복잡한 MQL5"를 비난합니다. 이전과 같이 공예품을 엉망으로 만들 수 없기 때문입니다. 그러나 처음에 수신 데이터를 확인하고 제어하여 코드를 생각하고 만든 사람들은 언어의 복잡성에 차이를 느끼지 못했고 이제는 "복잡성이 어디에 있습니까? 모든 것이 동일합니다 ..."
#property strict 없이 0으로 나누는 것은 허용되고 행성은 블랙홀로 붕괴되지 않지만 때로는 정말로 0으로 나누고 싶지만 허용하지 않습니다.
Nikolay, MQL4에 대해 걱정하지 마십시오. 모든 것이 정상입니다. Topikstarter는 무작위로 배열을 채웁니다 . 모두.
Artyom Trishkin :
물론 필요합니다.
자신과 자신의 프로그램을 존중하는 프로그래머는 모든 것이 순조롭게 진행되도록 내버려 두지 않을 것입니다. MQL4에서 #property strict를 사용하지 않으면 인덱스 20에서 크기가 10인 배열을 참조할 수 있습니다. 그리고 아무 일도 일어나지 않을 것입니다. 프로그램은 계속 작동하지만 프로그래머가 거기에서 무엇을 가져와 사용할 것입니까? 그의 어깨에. 그가 똑똑하다면 그는 배열 외부의 값을 얻지 않도록 모든 것을 확실히 확인하고 통제 할 것이지만 그가 "실수"라면 그는 그러한 통제에 신경 쓰지 않으며 "주요한 것은 그것은 작동하지만 어떻게 - 글쎄, 어떻게 - 스레드 ...". 대부분의 경우, 아무 것도 귀찮게하지 않고 울부 짖는 것은 그러한 사용자였습니다. 이제는 "나쁘고 사악하고 복잡한 MQL5"를 비난합니다. 이전과 같이 공예품을 엉망으로 만들 수 없기 때문입니다. 그러나 처음에 수신 데이터를 확인하고 제어하여 코드를 생각하고 만든 사람들은 언어의 복잡성에 차이를 느끼지 못했고 이제는 "복잡성이 어디에 있습니까? 모든 것이 동일합니다 ..."
주석! 음, Piotr은 MQL5의 엄격함 덕분에 코드를 상대적인 순서로 가져오고 쓰레기 더미를 분류할 기회가 있습니다. #property strict를 사용하여 고정 코드를 다시 MQL4로 컴파일하려고 시도할 수도 있으며 MT4에서 눈에 띄게 더 빠르게 작동할 수도 있습니다.
주석! 음, Piotr은 MQL5의 엄격함 덕분에 코드를 상대적인 순서로 가져오고 쓰레기 더미를 분류할 기회가 있습니다. #property strict를 사용하여 고정 코드를 다시 MQL4로 컴파일하려고 시도할 수도 있으며 MT4에서 눈에 띄게 더 빠르게 작동할 수도 있습니다.
그래서, 당신은 선험적으로 내 코드에 가비지 막힘이 있다고 결정했습니다.
나는 설명한다: 핵심은 여러 번의 방문으로 단계적으로 채워진다. MT5에서 배열을 선언할 때 가비지(나는 알지 못함)가 포함된 경우 함수에서 커널을 빌드하는 첫 번째 단계에서 배열은 변수에 대한 포인터 대신 하나의 커널 셀을 참조하기 때문에 한계를 넘어서게 됩니다. 다른 사람을 통해. 0이면 정상이고 두 번째 실행에서 원하는 값을 얻고 쓰레기가 포함되어 있으면 치명적인 오류가 발생합니다 .
저는 오버플로가 없습니다. 내 기술의 세부 사항을 고려하십시오(당신이 그것을 무시한다는 것을 잊었습니다). 한 셀에 대한 포인터로 배열의 다른 셀을 사용하고 그 안에 쓰레기가 있는 경우 배열을 넘어서게 됩니다. 문제는 참조하는 셀이 올바른 값을 얻으려면 커널 빌드의 두 번째 단계로 가야 한다는 것입니다. 그리고 두 번째 라운드에서는 값이 정확할 것입니다. 그러나 결정적인 실수 로 인해 2라운드에 진출하지 못할 것입니다.
이 모든 것은 선언된 배열의 쓰레기 때문입니다.
이는 1차 크기 설정(정규 영역 구성) 단계와 2차 커널 변경 단계에서 2차원 배열(커널)을 지우는 메커니즘을 마련할 필요가 있음을 의미한다. 크기, 사용자 영역을 구성할 때.
나는 설명한다: 핵심은 여러 번의 방문으로 단계적으로 채워진다. MT5에서 배열을 선언할 때 가비지(나는 알지 못함)가 포함된 경우 함수에서 커널을 빌드하는 첫 번째 단계에서 배열은 변수에 대한 포인터 대신 하나의 커널 셀을 참조하기 때문에 한계를 넘어서게 됩니다. 다른 사람을 통해. 0이면 정상이고 두 번째 실행에서 원하는 값을 얻고 쓰레기가 포함되어 있으면 치명적인 오류가 발생합니다 .
그럼 이해가 되시나요?
Reter 는 전혀 그렇지 않습니다. 비난해야 할 쓰레기는 아니지만 mql4에서 #property strict가 부족합니다. 이 가젯이 없으면 배열을 벗어나는 대신 0이 표시되고 mql5에는 이미 심각한 오류가 있습니다. 존재하지 않는 배열 인덱스의 내용보다 배열의 길이를 확인하는 것이 더 나을 것입니다.
Reter 는 전혀 그렇지 않습니다. 비난해야 할 쓰레기는 아니지만 mql4에서 #property strict가 부족합니다. 이 가젯이 없으면 배열을 벗어나는 대신 0이 표시되고 mql5에는 이미 심각한 오류가 있습니다. 존재하지 않는 배열 인덱스의 내용보다 배열의 길이를 확인하는 것이 더 나을 것입니다.
int Ширина_канваса = G_CORE[G_CORE[Окно][Его_канвас]][_X_SIZE];
Если G_CORE[Окно][Его_канвас] = 234523452345 ; (мусор) то ошибка. А если бы G_CORE[Окно][Его_канвас] = 0 ; Ошибки нет, и ядро продолжает нормально строится.
물론 필요합니다.
자신과 자신의 프로그램을 존중하는 프로그래머는 모든 것이 순조롭게 진행되도록 내버려 두지 않을 것입니다. MQL4에서 #property strict를 사용하지 않으면 인덱스 20에서 크기가 10인 배열을 참조할 수 있습니다. 그리고 아무 일도 일어나지 않을 것입니다. 프로그램은 계속 작동하지만 프로그래머가 거기에서 무엇을 가져와 사용할 것입니까? 그의 어깨에. 그가 똑똑하다면 그는 배열 외부의 값을 얻지 않도록 모든 것을 확실히 확인하고 통제 할 것이지만 그가 "실수"라면 그는 그러한 통제에 신경 쓰지 않으며 "주요한 것은 그것은 작동하지만 어떻게 - 글쎄, 어떻게 - 스레드 ...".
대부분의 경우, 아무 것도 귀찮게하지 않고 울부 짖는 것은 그러한 사용자였습니다. 이제는 "나쁘고 사악하고 복잡한 MQL5"를 비난합니다. 이전과 같이 공예품을 엉망으로 만들 수 없기 때문입니다. 그러나 처음에 수신 데이터를 확인하고 제어하여 코드를 생각하고 만든 사람들은 언어의 복잡성에 차이를 느끼지 못했고 이제는 "복잡성이 어디에 있습니까? 모든 것이 동일합니다 ..."
Nikolay, MQL4에 대해 걱정하지 마십시오. 모든 것이 정상입니다. Topikstarter는 무작위로 배열을 채웁니다 . 모두.
물론 필요합니다.
자신과 자신의 프로그램을 존중하는 프로그래머는 모든 것이 순조롭게 진행되도록 내버려 두지 않을 것입니다. MQL4에서 #property strict를 사용하지 않으면 인덱스 20에서 크기가 10인 배열을 참조할 수 있습니다. 그리고 아무 일도 일어나지 않을 것입니다. 프로그램은 계속 작동하지만 프로그래머가 거기에서 무엇을 가져와 사용할 것입니까? 그의 어깨에. 그가 똑똑하다면 그는 배열 외부의 값을 얻지 않도록 모든 것을 확실히 확인하고 통제 할 것이지만 그가 "실수"라면 그는 그러한 통제에 신경 쓰지 않으며 "주요한 것은 그것은 작동하지만 어떻게 - 글쎄, 어떻게 - 스레드 ...".
대부분의 경우, 아무 것도 귀찮게하지 않고 울부 짖는 것은 그러한 사용자였습니다. 이제는 "나쁘고 사악하고 복잡한 MQL5"를 비난합니다. 이전과 같이 공예품을 엉망으로 만들 수 없기 때문입니다. 그러나 처음에 수신 데이터를 확인하고 제어하여 코드를 생각하고 만든 사람들은 언어의 복잡성에 차이를 느끼지 못했고 이제는 "복잡성이 어디에 있습니까? 모든 것이 동일합니다 ..."
주석!
음, Piotr은 MQL5의 엄격함 덕분에 코드를 상대적인 순서로 가져오고 쓰레기 더미를 분류할 기회가 있습니다.
#property strict를 사용하여 고정 코드를 다시 MQL4로 컴파일하려고 시도할 수도 있으며 MT4에서 눈에 띄게 더 빠르게 작동할 수도 있습니다.
주석!
음, Piotr은 MQL5의 엄격함 덕분에 코드를 상대적인 순서로 가져오고 쓰레기 더미를 분류할 기회가 있습니다.
#property strict를 사용하여 고정 코드를 다시 MQL4로 컴파일하려고 시도할 수도 있으며 MT4에서 눈에 띄게 더 빠르게 작동할 수도 있습니다.
그래서, 당신은 선험적으로 내 코드에 가비지 막힘이 있다고 결정했습니다.
나는 설명한다: 핵심은 여러 번의 방문으로 단계적으로 채워진다. MT5에서 배열을 선언할 때 가비지(나는 알지 못함)가 포함된 경우 함수에서 커널을 빌드하는 첫 번째 단계에서 배열은 변수에 대한 포인터 대신 하나의 커널 셀을 참조하기 때문에 한계를 넘어서게 됩니다. 다른 사람을 통해. 0이면 정상이고 두 번째 실행에서 원하는 값을 얻고 쓰레기가 포함되어 있으면 치명적인 오류가 발생합니다 .
그럼 이해가 되시나요?
피터, 무슨 말인지 이해가 안 가?
그것이 바로 당신이 이해하지 못하는 것입니다. 그는 내 작업과 그의 ...
저는 오버플로가 없습니다. 내 기술의 세부 사항을 고려하십시오(당신이 그것을 무시한다는 것을 잊었습니다). 한 셀에 대한 포인터로 배열의 다른 셀을 사용하고 그 안에 쓰레기가 있는 경우 배열을 넘어서게 됩니다. 문제는 참조하는 셀이 올바른 값을 얻으려면 커널 빌드의 두 번째 단계로 가야 한다는 것입니다. 그리고 두 번째 라운드에서는 값이 정확할 것입니다. 그러나 결정적인 실수 로 인해 2라운드에 진출하지 못할 것입니다.
이 모든 것은 선언된 배열의 쓰레기 때문입니다.
이는 1차 크기 설정(정규 영역 구성) 단계와 2차 커널 변경 단계에서 2차원 배열(커널)을 지우는 메커니즘을 마련할 필요가 있음을 의미한다. 크기, 사용자 영역을 구성할 때.
그것이 바로 당신이 이해하지 못하는 것입니다. 그는 내 작업과 그의 ...
그리고 nuka는 독백을 만듭니다. 연속으로 10개의 메시지가 더 있습니다.
그래서, 당신은 선험적으로 내 코드에 가비지 막힘이 있다고 결정했습니다.
나는 설명한다: 핵심은 여러 번의 방문으로 단계적으로 채워진다. MT5에서 배열을 선언할 때 가비지(나는 알지 못함)가 포함된 경우 함수에서 커널을 빌드하는 첫 번째 단계에서 배열은 변수에 대한 포인터 대신 하나의 커널 셀을 참조하기 때문에 한계를 넘어서게 됩니다. 다른 사람을 통해. 0이면 정상이고 두 번째 실행에서 원하는 값을 얻고 쓰레기가 포함되어 있으면 치명적인 오류가 발생합니다 .
그럼 이해가 되시나요?
Reter 는 전혀 그렇지 않습니다. 비난해야 할 쓰레기는 아니지만 mql4에서 #property strict가 부족합니다. 이 가젯이 없으면 배열을 벗어나는 대신 0이 표시되고 mql5에는 이미 심각한 오류가 있습니다. 존재하지 않는 배열 인덱스의 내용보다 배열의 길이를 확인하는 것이 더 나을 것입니다.
Reter 는 전혀 그렇지 않습니다. 비난해야 할 쓰레기는 아니지만 mql4에서 #property strict가 부족합니다. 이 가젯이 없으면 배열을 벗어나는 대신 0이 표시되고 mql5에는 이미 심각한 오류가 있습니다. 존재하지 않는 배열 인덱스의 내용보다 배열의 길이를 확인하는 것이 더 나을 것입니다.
범위를 벗어난 것은 포인팅 셀에 쓰레기가 있기 때문에 발생합니다.
예를 들어:
처음에는:
G_CORE[객체][캔버스] = -123423452345; (쓰레기)
G_CORE[창][그것의 캔버스] = -452345; (쓰레기)
//------------------------------------------------ ------------------
결과는 범위를 벗어난 배열입니다.
반복합니다. 코어를 채우는 첫 번째 단계에서 일부 셀은 MT4에서 값이 0이고 두 번째 라운드에서 채워집니다.
MT5에서는 셀의 쓰레기로 인해 첫 번째 라운드에서 치명적인 오류 가 발생합니다.
배열 셀에 0이 있으면 오류가 발생하지 않고 커널이 순차적으로 채워집니다.
더 정확한 예는 다음과 같습니다.
코어 구축의 첫 번째 라운드. 기능 중 하나에서:
범위를 벗어난 것은 포인팅 셀에 쓰레기가 있기 때문에 발생합니다.
예를 들어:
처음에는:
G_CORE[객체][캔버스] = -123423452345; (쓰레기)
G_CORE[창][그것의 캔버스] = -452345; (쓰레기)
//------------------------------------------------ ------------------
결과는 범위를 벗어난 배열입니다.
반복합니다. 코어를 채우는 첫 번째 단계에서 일부 셀은 MT4에서 값이 0이고 두 번째 라운드에서 채워집니다.
MT5에서는 셀의 쓰레기로 인해 첫 번째 라운드에서 치명적인 오류 가 발생합니다.
배열 셀에 0이 있으면 오류가 발생하지 않고 커널이 순차적으로 채워집니다.
어레이 초기화 해제는 전적으로 코드 작성자의 잘못입니다. 자신의 실수를 찾으십시오. 알고리즘을 재구축하십시오.