이 표준, 법적 및 공통 C 표준 구성에 대해 편집자는 경고를 발행합니다. "'a' 선언은 4행에서 전역 선언을 숨깁니다." 및 "'b' 선언은 4행에서 전역 선언을 숨깁니다"는 여전히 정확하지 않으며 함수 내부에 새로운 변수의 선언도 없고, 최소한 변수의 중첩 가능성에 대한 힌트도 없기 때문에 본질적으로 문맹입니다.
결과적으로 너무 크지 않은 프로그램 코드에도 수백 개의 부적절한 경고가 있습니다.
글이 100% 맞습니다.
컴파일러에 대한 심층 제어의 유용성을 이해하려면 누군가에게 코드에 대한 전적인 책임을 지고 5-10년 간의 활성 프로그래밍이 필요합니다. C/C++ 언어는 품질을 깊이 분석하고 작성자를 보호하는 것을 꺼리고 능력이 없는 가장 약한 컴파일러 때문에 석궁이라는 명성을 얻었습니다.
2014년 현재에도 C/C++ 컴파일러(Microsoft가 완전히 파괴한 후 Windows에 남겨진 컴파일러)는 프로그래머를 스스로로부터 보호하지 않습니다. 예, 약간의 돈과 Visial Studio에서 별도로 시작된 Code Analysis에 대한 약한(실제로 쓸모 없음)이 있지만 여전히 깊은 오류 감지를 위해 PVS Studio , CPP Check 및 Lint를 별도로 사용해야 합니다.
이 예를 테스트:
MQL4/MQL5 - 잠재적 오류에 대한 경고 제공
declaration of 'a' hides global declaration at line 6 Test.mq4 1314
declaration of 'b' hides global declaration at line 6 Test.mq4 1322
코드 분석을 포함한 Visual Studio 2012 - 없음, 잠재적 오류에 대한 분석 품질은 일반적으로 0입니다. 오랫동안 경쟁자가 없기 때문에 그들은 증기 목욕을하지 않습니다.
PVS Studio가 올바르게 보고합니다.
V669 The 'a' , 'b' arguments are non-constant references. The analyzer is unable to determine the position at which this argument is being modified.
It is possible that the function contains an error. test.cpp 17
Lint - 유사하게 출력, 선언 'x' 숨기기...
우리의 임무는 품질 관리를 잘하고 자살/무모한 C/C++ 언어 기술의 사용을 허용하지 않는 품질 컴파일러를 만드는 것입니다.
1. 컴파일러가 경고하는 이 간단한 코드의 잠재적인 오류가 정확히 무엇인지 예를 들어 주시겠습니까?
합리적인 논리적 설명이 있고 너무 방해가 되는 형식을 취하지 않는다면 프로그래머를 돌보는 것은 확실히 좋은 일입니다.
2. 작성된 코드의 품질은 컴파일러의 품질 및 코드 구문을 분석하는 능력과는 아무런 관련이 없지만 잘 작성된 테스트 환경의 과정에서만 나타납니다. 작성된 코드의 심층 기능 분석을 수행합니다. 테스트 셸과 분리된 코드의 유익한 구문 분석을 믿는 것은 유토피아이며 에너지 낭비입니다.
그래서 전문 프로그래머는 경고를 거의 보지 않습니다. 컴파일러는 정의에 따라 기능적 코드 분석이 불가능 하고 초보 프로그래머 라도 어쨌든 언어의 구문을 알고 있기 때문입니다.
사실, 그들은 사실이지만 실용적이지 않습니다. 컴파일러의 이러한 동작을 제어할 수 없다는 것도 여기서 매우 중요합니다.
레나트 :
컴파일러에 대한 심층 제어의 유용성을 이해하려면 누군가에게 코드에 대한 전적인 책임을 지고 5-10년 간의 활성 프로그래밍이 필요합니다. C/C++ 언어는 품질을 깊이 분석하고 작성자를 보호하는 것을 꺼리고 능력이 없는 가장 약한 컴파일러 때문에 석궁이라는 명성을 얻었습니다.
그렇다면 왜 이러한 언어가 MQL4/MQL4++/MQL5의 기초로 채택되었는지 궁금합니다.
결국 요점은 무엇보다도 컴파일러가 아니라 이러한 언어의 구조에 있습니다.
레나트 :
2014년 현재에도 C/C++ 컴파일러(Microsoft가 완전히 파괴한 후 Windows에 남겨진 컴파일러)는 프로그래머를 스스로로부터 보호하지 않습니다. 예, 약간의 돈과 Visial Studio에서 별도로 시작된 Code Analysis에 대한 약함(실제로 쓸모 없음)이 있지만 여전히 깊은 오류 감지를 위해 PVS Studio , CPP Check 및 Lint를 별도로 사용해야 합니다.
이 예를 테스트:
MQL4/MQL5 - 잠재적 오류에 대한 경고 제공
코드 분석을 포함한 Visual Studio 2012 - 없음, 잠재적 오류에 대한 분석 품질은 일반적으로 0입니다. 오랫동안 경쟁자가 없기 때문에 그들은 증기 목욕을하지 않습니다.
PVS Studio가 올바르게 보고합니다.
Lint - 유사하게 출력, 선언 'x' 숨기기...
첫째, Microsoft는 전능하거나 편재하지 않습니다. 둘째, 2014년에는 Windows에 남아 있던 다른 컴파일러가 있습니다. 그러나 Linux에서 컴파일하는 예제를 제공하지만 "오류에 대한 심층 검색"이라는 측면에서 Windows와 Linux에서 이 컴파일러의 버전은 다르지 않습니다. 소스 코드가 약간 수정되었습니다.
int a= 1 ,b= 2 ;
//--------------------------------------------------------------------int sum( int & a, int & b){
return (a+b);
}
//--------------------------------------------------------------------int main(){
return sum(a,b);
}
컴파일 및 컴파일러 메시지:
$ icpc -c -Wremarks 1 .cpp
1 .cpp( 3 ): remark # 1418 : external function definition with no prior declarationint sum( int & a, int & b){
^
1 .cpp( 3 ): remark # 3280 : declaration hides variable "a" (declared at line 1 )int sum( int & a, int & b){
^
1 .cpp( 3 ): remark # 3280 : declaration hides variable "b" (declared at line 1 )int sum( int & a, int & b){
^
2014년에는 "심각한 오류 검색" 서비스를 제공하는 Windows용 컴파일러가 있습니다.
"심층 검색"을 사용할지 여부를 결정할 권리는 프로그래머에게 주어집니다. "-Wremarks" 옵션 없이 더 실질적으로 컴파일될 때 동일한 코드이지만 "-Wall" 옵션을 사용하여 모든 경고가 활성화된 경우 , 주석 없이 컴파일:
$ icpc -c -Wall 1 .cpp
$
또한 이 컴파일러를 사용하면 개별 발언 수준에서 "심층 검색"을 제어할 수 있으므로 프로그래머가 자신에게 불필요하다고 생각하는 발언은 금지됩니다.
다음 컴파일러 버전이 사용되었습니다.
$ icpc -- version
icpc (ICC) 15.0 . 020140723
Copyright (C) 1985 - 2014 Intel Corporation. All rights reserved.
그건 그렇고, 이 컴파일러는 Visual Studio에 통합되어 있으며 적어도 이전 버전은 Visual Studio의 이전 버전에 통합되어 있습니다.
레나트 :
우리의 임무는 품질 관리를 잘하고 자살/무모한 C/C++ 언어 기술의 사용을 허용하지 않는 품질 컴파일러를 만드는 것입니다.
고품질 컴파일러는 우선 최소한 "작동"해야 합니다. 즉, 언어 정의를 준수해야 합니다. 그렇지 않으면 다른 모든 이점의 의미가 완전히 손실됩니다.
#property strict/******************************************************************************/class A {
private :
/******************************************************************************/
A() { }
/******************************************************************************/void f() { }
public :
/******************************************************************************/staticvoid sf1(A &a) {
a.f(); // Нет ошибки
}
/******************************************************************************/staticvoid sf2() {
A a; // Место "ошибки"
a.f(); // Нет ошибки
}
};
/******************************************************************************/voidOnStart () {
}
private 섹션에 선언된 f() 메서드가 정적 메서드에서 완벽하게 호출되어야 하는 것처럼 왜 동일한 정적 메서드에서 클래스 생성자가 비공개 섹션에 선언되어 있으면 더 이상 "호출"되지 않습니다. 변수가 정의되어 있습니까?
오류 메시지:
'A::A' - cannot call private member function
이 컴파일러 버그는 예를 들어 사람의 방식으로 Myers 싱글톤을 구현하는 것을 허용하지 않습니다(이 예제는 언급된 싱글톤의 구현이 아닙니다). 그리고 이것은 private 섹션에 선언된 엔터티에 대한 액세스 측면에서 마지막 버그가 아닙니다.
이것은 버그이며, 예를 들어 자살/무모한 관행을 겨냥한 기능이 아닙니다. 자동 변수의 정의를 동적 개체 생성으로 바꾸자마자 생성자가 갑자기 가장 놀라운 부분에서 호출되기 시작하기 때문입니다. 방법:
/******************************************************************************/staticvoid sf2() {
A *a = new A;
a.f();
delete a;
}
이 코드는 오류 없이 컴파일됩니다. 또한 이 경우 생성자가 이미 호출되었음을 확인하려면 생성자 코드에서 일부 메시지의 출력물을 삽입하여 확인할 수 있습니다.
이러한 버그가 남아 있는 동안 품질 컴파일러에 대해 이야기하는 것이 이상합니다. 언어 구현 자체의 오류 측면에서 상업용 및 비상업용 C/C++ 컴파일러는 그러한 불명예가 없기 때문에 MQL4++ 컴파일러보다 훨씬 우수합니다. 그것들과 비교할 때 MQL4++ 컴파일러가 전혀 "작동"하지 않는다고 말할 수 있습니다.
이 단계에서 정말 심각한 코드 품질 관리를 제공하는 MQL4++ 컴파일러의 유일한 정말 강력한 기능은 프로그래머의 코드가 실패할 수 있는 함수(예: 거래 기능)에서 반환된 값을 제어하지 않는 경우 경고하는 것입니다. 그러나 컴파일러의 그러한 강력한 기능조차도 언어 구현의 열악한 품질을 감안할 때 매우 제한적인 가치가 있습니다.
잠재적 오류는 잠재적 오류이며 반드시 오류는 아닙니다. 따라서 "이러한 오류를 수정해야 함을 의미한다"는 진술은 오류가 전혀 아닐 수 있으므로 올바르지 않습니다.
함수 호출 의 결과를 확인하지 않는 경우와 같이 거의 확실하게 오류가 있는 경우가 있는데, 실패할 수 있습니다. 그러한 경우에 대한 경고는 적절하고 매우 유용합니다. 그리고 오류가 있는지 여부를 알 수 없는 경우에 대한 경고는 일반적으로 부적절하고 도움이 되지 않습니다. 이름을 숨기는 경우 오류가 거의 발생한다고 말할 수 없습니다.
예, 프로그래머는 잠재적인 오류, 즉 실수로 발생한 오류가 있는지 확인하기 위해 "심층 검색"을 기반으로 하는 모든 종류의 진단을 받을 수 있습니다. 그러나 이것은 컴파일러의 기본 모드가 아니어야 하며 이 모드는 비활성화할 수 있어야 합니다. 이러한 종류의 잠재적인 오류로부터 초보자를 보호하기 위해 기본적으로, 즉 설치 후 진단이 활성화될 수 있습니다. 그러나 여전히 끌 수 있는 옵션이 있어야 합니다.
분명히 인텔 컴파일러에서 이전에 외부 범위에서 선언된 이름이 중첩 범위에 숨겨져 있다는 사실은 경고가 아닌 주석으로만 감지됩니다. 같은 이유로 이것은 오류가 아닐 수 있습니다. 비상업적인 컴파일러를 포함한 다른 컴파일러에서는 이러한 은폐 사실이 경고에 해당하지 않습니다. 컴파일러 사용자, 즉 프로그래머의 전체 집단 경험은 이것이 경고가 되어서는 안 된다고 제안하기 때문입니다. 그리고 물론 사용자는 어떤 경고/설명이 발행되고 어떤 경고/설명이 발행되지 않을지 구성할 수 있어야 합니다.
그건 그렇고, MQL은 C/C++ 표준을 따를 필요가 없는 별도의 언어이기 때문에 중첩 범위에서 이름 숨기기를 완전히 금지하는 것이 더 쉽지 않습니까?
1 .cpp( 3 ): remark # 3280 : declaration hides variable "a" (declared at line 1 )int sum( int & a, int & b){
이 언급은 의미가 없고 원칙적으로 프로그래머에게 유용한 정보를 전달하지 않습니다. 왜냐하면 언급한 바와 같이 처음에는 변수 "a"가 숨겨져 있지 않기 때문입니다.
은닉은 변수의 로컬 복사본이 만들어질 때만 발생하며 이는 완벽하게 합법입니다. 이 숨김으로 인해 갑자기 코드의 오류가 발생하더라도 바로 검색하면 같은 이름을 찾기 때문에 쉽게 정확하게 찾을 수 있습니다. 함수 템플릿에서 이름을 변경하고 맹글링하기 시작하고 이것이 컴파일러의 논리에 따라 정확히 이 설명의 "해결책"이라면 오류를 찾는 상황이 훨씬 더 어려워지고 혼란이 측량할 수 없을 정도로 증가할 것입니다. 코드 이해하기. 분명한 것 같습니다.
이봐 비닌!
지표를 확인하셨나요? : AltrTrend_Signal_v2_2.mq4
논리적 오류를 발견했습니다.
~에 공식 : SSP=MathCeil(Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1));
당신은 끝에 1에 밑줄을 긋습니다
여기에 무엇이 있어야 한다고 생각합니까?
판사
아마 0! 시도 해봐! 그리고 루프에 있다면 i 또는 무엇이든 시도하십시오!
이봐 비닌!
지표를 확인하셨나요? : AltrTrend_Signal_v2_2.mq4
논리적 오류를 발견했습니다.
~에 공식 : SSP=MathCeil(Kperiod/iADX(NULL,0,PerADX,PRICE_CLOSE,MODE_MAIN,1));
당신은 끝에 1에 밑줄을 긋습니다
여기에 무엇이 있어야 한다고 생각합니까?
판사
교대 해야 한다
이 표준, 법적 및 공통 C 표준 구성에 대해 편집자는 경고를 발행합니다. "'a' 선언은 4행에서 전역 선언을 숨깁니다." 및 "'b' 선언은 4행에서 전역 선언을 숨깁니다"는 여전히 정확하지 않으며 함수 내부에 새로운 변수의 선언도 없고, 최소한 변수의 중첩 가능성에 대한 힌트도 없기 때문에 본질적으로 문맹입니다.
결과적으로 너무 크지 않은 프로그램 코드에도 수백 개의 부적절한 경고가 있습니다.
글이 100% 맞습니다.
컴파일러에 대한 심층 제어의 유용성을 이해하려면 누군가에게 코드에 대한 전적인 책임을 지고 5-10년 간의 활성 프로그래밍이 필요합니다. C/C++ 언어는 품질을 깊이 분석하고 작성자를 보호하는 것을 꺼리고 능력이 없는 가장 약한 컴파일러 때문에 석궁이라는 명성을 얻었습니다.
2014년 현재에도 C/C++ 컴파일러(Microsoft가 완전히 파괴한 후 Windows에 남겨진 컴파일러)는 프로그래머를 스스로로부터 보호하지 않습니다. 예, 약간의 돈과 Visial Studio에서 별도로 시작된 Code Analysis에 대한 약한(실제로 쓸모 없음)이 있지만 여전히 깊은 오류 감지를 위해 PVS Studio , CPP Check 및 Lint를 별도로 사용해야 합니다.
이 예를 테스트:
우리의 임무는 품질 관리를 잘하고 자살/무모한 C/C++ 언어 기술의 사용을 허용하지 않는 품질 컴파일러를 만드는 것입니다.
나는 또한 메시지가 완전히 쓸모 없다고 생각합니다. 나는 전문 프로그래머는 아니지만 마이크로 리터의 그런 넌센스는 나를 짜증나게합니다. 흥미롭게도 및 b에 대한 참조가 일정하면 PVS Studio에서 경고를 표시합니다(직접 확인할 방법이 없음)?
이 예를 테스트:
1. 컴파일러가 경고하는 이 간단한 코드의 잠재적인 오류가 정확히 무엇인지 예를 들어 주시겠습니까?
합리적인 논리적 설명이 있고 너무 방해가 되는 형식을 취하지 않는다면 프로그래머를 돌보는 것은 확실히 좋은 일입니다.
2. 작성된 코드의 품질은 컴파일러의 품질 및 코드 구문을 분석하는 능력과는 아무런 관련이 없지만 잘 작성된 테스트 환경의 과정에서만 나타납니다. 작성된 코드의 심층 기능 분석을 수행합니다. 테스트 셸과 분리된 코드의 유익한 구문 분석을 믿는 것은 유토피아이며 에너지 낭비입니다.
그래서 전문 프로그래머는 경고를 거의 보지 않습니다. 컴파일러는 정의에 따라 기능적 코드 분석이 불가능 하고 초보 프로그래머 라도 어쨌든 언어의 구문을 알고 있기 때문입니다.
글이 100% 맞습니다.
사실, 그들은 사실이지만 실용적이지 않습니다. 컴파일러의 이러한 동작을 제어할 수 없다는 것도 여기서 매우 중요합니다.
컴파일러에 대한 심층 제어의 유용성을 이해하려면 누군가에게 코드에 대한 전적인 책임을 지고 5-10년 간의 활성 프로그래밍이 필요합니다. C/C++ 언어는 품질을 깊이 분석하고 작성자를 보호하는 것을 꺼리고 능력이 없는 가장 약한 컴파일러 때문에 석궁이라는 명성을 얻었습니다.
그렇다면 왜 이러한 언어가 MQL4/MQL4++/MQL5의 기초로 채택되었는지 궁금합니다.
결국 요점은 무엇보다도 컴파일러가 아니라 이러한 언어의 구조에 있습니다.
2014년 현재에도 C/C++ 컴파일러(Microsoft가 완전히 파괴한 후 Windows에 남겨진 컴파일러)는 프로그래머를 스스로로부터 보호하지 않습니다. 예, 약간의 돈과 Visial Studio에서 별도로 시작된 Code Analysis에 대한 약함(실제로 쓸모 없음)이 있지만 여전히 깊은 오류 감지를 위해 PVS Studio , CPP Check 및 Lint를 별도로 사용해야 합니다.
이 예를 테스트:
첫째, Microsoft는 전능하거나 편재하지 않습니다. 둘째, 2014년에는 Windows에 남아 있던 다른 컴파일러가 있습니다. 그러나 Linux에서 컴파일하는 예제를 제공하지만 "오류에 대한 심층 검색"이라는 측면에서 Windows와 Linux에서 이 컴파일러의 버전은 다르지 않습니다. 소스 코드가 약간 수정되었습니다.
컴파일 및 컴파일러 메시지:
2014년에는 "심각한 오류 검색" 서비스를 제공하는 Windows용 컴파일러가 있습니다.
"심층 검색"을 사용할지 여부를 결정할 권리는 프로그래머에게 주어집니다. "-Wremarks" 옵션 없이 더 실질적으로 컴파일될 때 동일한 코드이지만 "-Wall" 옵션을 사용하여 모든 경고가 활성화된 경우 , 주석 없이 컴파일:
$ icpc -c -Wall 1 .cpp $또한 이 컴파일러를 사용하면 개별 발언 수준에서 "심층 검색"을 제어할 수 있으므로 프로그래머가 자신에게 불필요하다고 생각하는 발언은 금지됩니다.
다음 컴파일러 버전이 사용되었습니다.
그건 그렇고, 이 컴파일러는 Visual Studio에 통합되어 있으며 적어도 이전 버전은 Visual Studio의 이전 버전에 통합되어 있습니다.
우리의 임무는 품질 관리를 잘하고 자살/무모한 C/C++ 언어 기술의 사용을 허용하지 않는 품질 컴파일러를 만드는 것입니다.
고품질 컴파일러는 우선 최소한 "작동"해야 합니다. 즉, 언어 정의를 준수해야 합니다. 그렇지 않으면 다른 모든 이점의 의미가 완전히 손실됩니다.
private 섹션에 선언된 f() 메서드가 정적 메서드에서 완벽하게 호출되어야 하는 것처럼 왜 동일한 정적 메서드에서 클래스 생성자가 비공개 섹션에 선언되어 있으면 더 이상 "호출"되지 않습니다. 변수가 정의되어 있습니까?
오류 메시지:
이 컴파일러 버그는 예를 들어 사람의 방식으로 Myers 싱글톤을 구현하는 것을 허용하지 않습니다(이 예제는 언급된 싱글톤의 구현이 아닙니다). 그리고 이것은 private 섹션에 선언된 엔터티에 대한 액세스 측면에서 마지막 버그가 아닙니다.
이것은 버그이며, 예를 들어 자살/무모한 관행을 겨냥한 기능이 아닙니다. 자동 변수의 정의를 동적 개체 생성으로 바꾸자마자 생성자가 갑자기 가장 놀라운 부분에서 호출되기 시작하기 때문입니다. 방법:
이 코드는 오류 없이 컴파일됩니다. 또한 이 경우 생성자가 이미 호출되었음을 확인하려면 생성자 코드에서 일부 메시지의 출력물을 삽입하여 확인할 수 있습니다.
이러한 버그가 남아 있는 동안 품질 컴파일러에 대해 이야기하는 것이 이상합니다. 언어 구현 자체의 오류 측면에서 상업용 및 비상업용 C/C++ 컴파일러는 그러한 불명예가 없기 때문에 MQL4++ 컴파일러보다 훨씬 우수합니다. 그것들과 비교할 때 MQL4++ 컴파일러가 전혀 "작동"하지 않는다고 말할 수 있습니다.
이 단계에서 정말 심각한 코드 품질 관리를 제공하는 MQL4++ 컴파일러의 유일한 정말 강력한 기능은 프로그래머의 코드가 실패할 수 있는 함수(예: 거래 기능)에서 반환된 값을 제어하지 않는 경우 경고하는 것입니다. 그러나 컴파일러의 그러한 강력한 기능조차도 언어 구현의 열악한 품질을 감안할 때 매우 제한적인 가치가 있습니다.
나는 또한 메시지가 완전히 쓸모 없다고 생각합니다. 나는 전문 프로그래머는 아니지만 마이크로 리터의 그런 넌센스는 나를 짜증나게합니다. 흥미롭게도 및 b에 대한 참조가 일정하면 PVS Studio에서 경고를 표시합니다(직접 확인할 방법이 없음)?
사실, 그들은 사실이지만 실용적이지 않습니다.
글쎄요, 잠재적 오류의 표시가 정확하면 이러한 오류를 수정해야 합니다.
잠재적 오류는 잠재적 오류이며 반드시 오류는 아닙니다. 따라서 "이러한 오류를 수정해야 함을 의미한다"는 진술은 오류가 전혀 아닐 수 있으므로 올바르지 않습니다.
함수 호출 의 결과를 확인하지 않는 경우와 같이 거의 확실하게 오류가 있는 경우가 있는데, 실패할 수 있습니다. 그러한 경우에 대한 경고는 적절하고 매우 유용합니다. 그리고 오류가 있는지 여부를 알 수 없는 경우에 대한 경고는 일반적으로 부적절하고 도움이 되지 않습니다. 이름을 숨기는 경우 오류가 거의 발생한다고 말할 수 없습니다.
예, 프로그래머는 잠재적인 오류, 즉 실수로 발생한 오류가 있는지 확인하기 위해 "심층 검색"을 기반으로 하는 모든 종류의 진단을 받을 수 있습니다. 그러나 이것은 컴파일러의 기본 모드가 아니어야 하며 이 모드는 비활성화할 수 있어야 합니다. 이러한 종류의 잠재적인 오류로부터 초보자를 보호하기 위해 기본적으로, 즉 설치 후 진단이 활성화될 수 있습니다. 그러나 여전히 끌 수 있는 옵션이 있어야 합니다.
분명히 인텔 컴파일러에서 이전에 외부 범위에서 선언된 이름이 중첩 범위에 숨겨져 있다는 사실은 경고가 아닌 주석으로만 감지됩니다. 같은 이유로 이것은 오류가 아닐 수 있습니다. 비상업적인 컴파일러를 포함한 다른 컴파일러에서는 이러한 은폐 사실이 경고에 해당하지 않습니다. 컴파일러 사용자, 즉 프로그래머의 전체 집단 경험은 이것이 경고가 되어서는 안 된다고 제안하기 때문입니다. 그리고 물론 사용자는 어떤 경고/설명이 발행되고 어떤 경고/설명이 발행되지 않을지 구성할 수 있어야 합니다.
그건 그렇고, MQL은 C/C++ 표준을 따를 필요가 없는 별도의 언어이기 때문에 중첩 범위에서 이름 숨기기를 완전히 금지하는 것이 더 쉽지 않습니까?
이 언급은 의미가 없고 원칙적으로 프로그래머에게 유용한 정보를 전달하지 않습니다. 왜냐하면 언급한 바와 같이 처음에는 변수 "a"가 숨겨져 있지 않기 때문입니다.
은닉은 변수의 로컬 복사본이 만들어질 때만 발생하며 이는 완벽하게 합법입니다. 이 숨김으로 인해 갑자기 코드의 오류가 발생하더라도 바로 검색하면 같은 이름을 찾기 때문에 쉽게 정확하게 찾을 수 있습니다. 함수 템플릿에서 이름을 변경하고 맹글링하기 시작하고 이것이 컴파일러의 논리에 따라 정확히 이 설명의 "해결책"이라면 오류를 찾는 상황이 훨씬 더 어려워지고 혼란이 측량할 수 없을 정도로 증가할 것입니다. 코드 이해하기. 분명한 것 같습니다.