Andrei01 : 어느 것에도 없습니다. 참조로 변수를 전달할 때 로컬 복사본이 생성되지 않고 전달된 변수로 직접 작업이 수행됩니다. 그래서 여기에서 무슨 은폐가 일어나고 있습니까?
여기서 이름 숨기기가 발생합니다. 다른 모든 것 - 사본이 아닌 사본 -은 부차적입니다. 함수 내에서 링크의 이름을 사용하면 링크가 참조하는 객체로 작업이 수행됩니다. 외부 범위의 개체를 참조하는 경우 작업이 완료됩니다. 그러나 다른 경우와 마찬가지로 숨김이라는 이름이 없기 때문이 아니라 참조가 이 개체를 가리키기 때문입니다. 이런 식으로 함수를 호출합니다. 이 개체는 참조로 전달되었으며 이제 개체를 가리킵니다. 다른 객체를 호출할 때 호출되고 전달되면 동일한 함수 코드가 다른 객체와 함께 작동합니다.
나는 은닉이 적용/참조되고 다른 모든 것은 부차적이라는 것을 보여주기 위해 유형 이름과 변수 이름, 즉 본질적으로 가능한 한 다른 엔터티가 있는 예를 제공했습니다.
그러나 MQL4++에서 이 주제에 대한 다른 예제를 생성하려고 하는 동안 MQL4++에서 매개변수에 대한 추가 범위가 생성된다는 것을 우연히 발견했습니다. 그리고 지역 변수의 범위 는 이미 중첩되어 있습니다.
#property strictvoid f( int a) {
int saved = a;
int a = a + 1 ;
Print ( "saved = " , saved, ", a = " , a);
}
voidOnStart () {
f( 3 );
}
이 예제는 특정 경고와 함께 컴파일됩니다.
declaration of 'a' hides local declaration at line 33 .mq4 57
물론 모든 것이 매끄럽고 매트 아래에서 진행되는 것은 아닙니다. 다음은 최종 사용자에게 도달하는 제품을 테스트할 때 개발자가 생략한 몇 가지입니다. 그러나 MT4는 다중 통화 전략(테스트)에 강하지 않지만 개선이 필요합니다. 그래서 지금도 언젠가는 그렇게 되기를 바라며..
프로그래밍을 줄이지 말고 실제에 가지 말고 지금 데모를 사용하십시오. 항상 그렇듯이 나쁜 댄서는 황금색과 분홍색을 포함한 "계란"에 의해 방해를 받습니다.
경고의 본질의 관점에서 이것은 중요하지 않습니다. 또한 변수가 참조 또는 값으로 전달되는지 여부는 중요하지 않습니다.
변수 자체를 전달하는 것과 함수에서 변수를 수정하고 복사본을 만드는 것 사이에는 경고의 성격에 큰 차이가 있지만 변수 자체는 변경되지 않습니다.
글쎄, 경고를 끄거나 사용자 정의 할 수 없다는 사실, 이것이 고전적인 MK 기업 스타일입니다 - "가지마세요" :)) 그것에 대해 아무 것도 할 수 없지만 기본적이고 겸손하게 받아 들여지는 스타일이기 때문에 그것은 종교적 속성의 범주로 격상되었습니다 ... 실천이 보여주듯이 적어도 여기에서 논리와 정의를 찾는 것은 쓸모가 없습니다. ))
잠재적 오류는 잠재적 오류이며 반드시 오류는 아닙니다. 따라서 "이러한 오류를 수정해야 함을 의미한다"는 진술은 오류가 전혀 아닐 수 있으므로 올바르지 않습니다.
...
여기 사람들이 이상합니다. 그런 돈키호테는 풍차처럼 컴파일러와 싸웁니다. 중요한 것은 컴파일러가 당신의 동맹이라는 것입니다! 컴파일러가 코드의 잠재적으로 위험한 부분에 대해 맹세하게 되어 기쁩니다. 응용 프로그램이 실행된 직후 오류 행과 함께 충돌하는 경우에도 기뻐하십시오. 그러나 오류 및 경고가없고 프로그램이 외부적으로 정상적으로 작동하지만 때때로 이상한 결함이 나타나기 시작하는 경우 관리되지 않는 코드를 얻는 것을 금지합니다. 그 원인은 어디에도 없습니다. 그런 순간에, 당신은 증기에 덮여 " 유효하지 않은 포인터 " 또는 "0으로 나누기"와 같은 오류에 대해 꿈을 꾸기 시작합니다.
C-4 : 그러나 오류 및 경고가없고 프로그램이 외부적으로 정상적으로 작동하지만 때때로 이상한 결함이 나타나기 시작하는 경우 관리되지 않는 코드를 얻는 것을 금지합니다. 그 원인은 어디에도 없습니다. 그러한 순간에, 당신은 증기로 뒤덮이고 "잘못된 포인터" 또는 "0으로 나누기"와 같은 오류에 대한 꿈을 꾸기 시작합니다.
컴파일러는 그것과 아무 관련이 없습니다. 이것은 정의되지 않았거나 잘못된 상태가 가능한 코드의 위험한 위치에 테스트 검사가 없을 때 전형적인 비뚤어진 작성입니다. 이것이 글리치가 나오는 이유입니다.
기능 코드 검사는 컴파일러와 아무 관련이 없으며 처음에 컴파일러에서 기대하는 것은 의미가 없습니다.
다시 말하지만, 전문 프로그래머는 일반적으로 경고를 보지 않습니다. 왜냐하면 그들은 이미 컴파일러의 논리를 알고 있고 컴파일러는 코드의 기능을 확인하는 데 쓸모가 없기 때문입니다.
지역 변수와 매개 변수는 같은 범위에 있으므로 매개 변수에 이러한 이름이나 지역 변수가 있는지 여부는 중요하지 않지만 어떤 경우에도 이 이름은 외부 범위에서 이름을 숨깁니다.
어느 것에도 없습니다. 참조로 변수를 전달할 때 로컬 복사본이 생성되지 않고 전달된 변수로 직접 작업이 수행됩니다. 그래서 여기에서 무슨 은폐가 일어나고 있습니까?
여기서 이름 숨기기가 발생합니다. 다른 모든 것 - 사본이 아닌 사본 -은 부차적입니다. 함수 내에서 링크의 이름을 사용하면 링크가 참조하는 객체로 작업이 수행됩니다. 외부 범위의 개체를 참조하는 경우 작업이 완료됩니다. 그러나 다른 경우와 마찬가지로 숨김이라는 이름이 없기 때문이 아니라 참조가 이 개체를 가리키기 때문입니다. 이런 식으로 함수를 호출합니다. 이 개체는 참조로 전달되었으며 이제 개체를 가리킵니다. 다른 객체를 호출할 때 호출되고 전달되면 동일한 함수 코드가 다른 객체와 함께 작동합니다.
나는 은닉이 적용/참조되고 다른 모든 것은 부차적이라는 것을 보여주기 위해 유형 이름과 변수 이름, 즉 본질적으로 가능한 한 다른 엔터티가 있는 예를 제공했습니다.
그러나 MQL4++에서 이 주제에 대한 다른 예제를 생성하려고 하는 동안 MQL4++에서 매개변수에 대한 추가 범위가 생성된다는 것을 우연히 발견했습니다. 그리고 지역 변수의 범위 는 이미 중첩되어 있습니다.
이 예제는 특정 경고와 함께 컴파일됩니다.
그리고 앞으로 성공적으로 실행됩니다.
분명히 MQL4++에서는 매개변수에 대해 "계층화된" 범위가 하나 더 생성되었습니다. 그렇기 때문에 매개변수 이름과 같은 이름으로 지역 변수를 선언할 수 있습니다.
C/C++에는 다음과 같은 "계층"이 없습니다.
컴파일러는 일반적으로 주어진 범위에 이 이름을 가진 변수가 이미 있다고 설명합니다.
즉, 함수 매개변수와 해당 지역 변수의 범위가 동일합니다.
MQL4++에서 이것이 사실이 아닌 이유는 무엇입니까? 물론 흥미로운 질문입니다...
이 예제는 특정 경고와 함께 컴파일됩니다.
이 경우 로컬 복사본 생성이 아니라 참조로 변수를 전달하고 오류 경고가 발생하는 경우에 대해 설명합니다.
처음 몇 개의 게시물만 읽었습니다.
물론 모든 것이 매끄럽고 매트 아래에서 진행되는 것은 아닙니다. 다음은 최종 사용자에게 도달하는 제품을 테스트할 때 개발자가 생략한 몇 가지입니다. 그러나 MT4는 다중 통화 전략(테스트)에 강하지 않지만 개선이 필요합니다. 그래서 지금도 언젠가는 그렇게 되기를 바라며..
프로그래밍을 줄이지 말고 실제에 가지 말고 지금 데모를 사용하십시오. 항상 그렇듯이 나쁜 댄서는 황금색과 분홍색을 포함한 "계란"에 의해 방해를 받습니다.
행운을 빕니다!
이 경우 참조로 변수를 전달하고 오류 경고가 발생하는 경우에 대해 설명하고 로컬 복사본을 생성하지 않습니다.
경고의 본질의 관점에서 이것은 중요하지 않습니다. 또한 변수가 참조로 전달되는지 아니면 값으로 전달되는지 뿐만 아니라 유형이 무엇인지도 중요하지 않습니다.
코드가 컴파일되고 논의된 경고가 발행됩니다.
어떤 이유로 당신은 그것을 이해하고 싶지 않습니다.
경고 자체는 조금도 잘못된 것이 아닙니다. 또한, MQL4++의 추적 범위는 다른 작업이 수행되는 방식에 비해 놀라울 정도로 잘 수행됩니다.
경고는 사실이지만 실용적이지 않고 끌 수도 없습니다. 바로 이것이 핵심입니다. 그러나 참조로 전달하지 않습니다.
경고의 본질의 관점에서 이것은 중요하지 않습니다. 또한 변수가 참조 또는 값으로 전달되는지 여부는 중요하지 않습니다.
변수 자체를 전달하는 것과 함수에서 변수를 수정하고 복사본을 만드는 것 사이에는 경고의 성격에 큰 차이가 있지만 변수 자체는 변경되지 않습니다.
글쎄, 경고를 끄거나 사용자 정의 할 수 없다는 사실, 이것이 고전적인 MK 기업 스타일입니다 - "가지마세요" :)) 그것에 대해 아무 것도 할 수 없지만 기본적이고 겸손하게 받아 들여지는 스타일이기 때문에 그것은 종교적 속성의 범주로 격상되었습니다 ... 실천이 보여주듯이 적어도 여기에서 논리와 정의를 찾는 것은 쓸모가 없습니다. ))
Ugh uh 모든 메타 인용문은 나를 위해 시계처럼 작동합니다
전혀 불만이 없습니다.
잠재적 오류는 잠재적 오류이며 반드시 오류는 아닙니다. 따라서 "이러한 오류를 수정해야 함을 의미한다"는 진술은 오류가 전혀 아닐 수 있으므로 올바르지 않습니다.
...
그러나 오류 및 경고가없고 프로그램이 외부적으로 정상적으로 작동하지만 때때로 이상한 결함이 나타나기 시작하는 경우 관리되지 않는 코드를 얻는 것을 금지합니다. 그 원인은 어디에도 없습니다. 그러한 순간에, 당신은 증기로 뒤덮이고 "잘못된 포인터" 또는 "0으로 나누기"와 같은 오류에 대한 꿈을 꾸기 시작합니다.
컴파일러는 그것과 아무 관련이 없습니다. 이것은 정의되지 않았거나 잘못된 상태가 가능한 코드의 위험한 위치에 테스트 검사가 없을 때 전형적인 비뚤어진 작성입니다. 이것이 글리치가 나오는 이유입니다.
기능 코드 검사는 컴파일러와 아무 관련이 없으며 처음에 컴파일러에서 기대하는 것은 의미가 없습니다.
다시 말하지만, 전문 프로그래머는 일반적으로 경고를 보지 않습니다. 왜냐하면 그들은 이미 컴파일러의 논리를 알고 있고 컴파일러는 코드의 기능을 확인하는 데 쓸모가 없기 때문입니다.
변수 자체를 전달하는 것과 함수에서 변수를 수정하고 복사본을 만드는 것 사이에는 경고의 성격에 큰 차이가 있지만 변수 자체는 변경되지 않습니다.
이것은 또 다른 유형의 경고일 뿐입니다. 이름 숨기기에 대해.
그리고 변수 자체는 전달되지 않습니다. 그것에 대한 링크를 보냅니다.