여기서 반대로 포인터 는 암시적으로 개체로 캐스팅(역참조)된 다음 연산자 =가 개체에 적용됩니다. 어제 fxsaber도 이것을 언급했습니다.
그리고 이 경우 그러한 행위를 금지하는 것이 낫다는 데 동의합니다. 논리적으로 MQL 규칙과 모순되지는 않지만(= 연산자를 호출하는 것은 다른 개체 메서드를 호출하는 것과 동일하기 때문에) 이러한 코드에 대한 모호한 인식과 미묘한 오류로 이어집니다. 그리고 이것은 = 연산자뿐만 아니라 적어도 == 및 !=에도 적용됩니다. 그리고 아마도 다른 운영자의 경우 그러한 캐스팅을 금지해야 할 필요가 있습니다. C++에서는 +-<>[] 연산자에 적용할 수 있기 때문입니다.
간단히 말해서 평결은 다음과 같습니다. C++에서 포인터에 대해 허용되는 포인터에 연산자를 적용할 때 이 포인터를 개체에 암시적으로 캐스팅하는 것을 금지합니다. 따라서 위의 예에서는 컴파일 오류가 발생 합니다.
네, 이해할 수 있습니다. 이 간단한 예를 사용하여 포인터와 개체가 다른 개체이며 어떤 식으로든 간섭할 수 없다고 의심하는 모든 사람들을 보여주고 싶었습니다.
그리고 이 상황은 최소한 특정 스타일의 코드 작성을 의미하므로 실수로(지식이 아닌) 컴파일하고 테스트를 통과하지만 실제 조건에서 실패하는 코드를 작성하지 않으며 판매용으로 작성된 경우 훨씬 더 나쁩니다. . 모든 것이 "암시적으로" 동일한 코드에서 오류 위치를 찾는 것은 다소 어려운 작업이 될 것입니다.
유형 A a = 새로운 A? 또는 구체적으로) strict는 이제 모든 사람이 사용하므로 전혀 효과가 없습니다.
여기서 A 유형의 쓰기 저장이 있는 경우 a, *b = a; 런타임 오류가 발생하며, 이 경우 컴파일러는 다른 모든 유형과 마찬가지로 "초기화되지 않은 변수 'b'의 사용 가능성" 경고를 명시적으로 발행해야 합니다. 컴파일 오류 가 전혀 아닌 경우. 그러나 할당 자체 때문이 아니라 초기화되지 않은 변수에 오버로드된 함수를 사용하기 때문에 당연히 런타임 오류가 발생합니다. 이것은 정말 버그이며 과도한 코드 최적화와 관련이 있는 것 같습니다.
일반적으로 자동차를 다이노에 할당하는 데 이단은 없으며 그 반대도 마찬가지입니다. 유용한 칩이 될 수 있습니다.
그러나 나는 객체의 묵시적 복사와 같은 기능을 완전히 취소할 것입니다. With ++의 표준이기도 하지만. 사실 그 때문에 이러한 모든 문제가 발생합니다.
객체에 대한 이 포인터의 암시적 캐스팅
"암시적 포인터 역참조"라고 부르는 것이 더 정확할 것입니다.
나는 다음과 같이 클래스 멤버 를 참조할 때만 암시적 역참조를 금지하고 남겨두자는 제안을 지지합니다.
여기서 반대로 포인터 는 암시적으로 개체로 캐스팅(역참조)된 다음 연산자 =가 개체에 적용됩니다. 어제 fxsaber도 이것을 언급했습니다.
그리고 이 경우 그러한 행위를 금지하는 것이 낫다는 데 동의합니다. 논리적으로 MQL 규칙과 모순되지는 않지만(= 연산자를 호출하는 것은 다른 개체 메서드를 호출하는 것과 동일하기 때문에) 이러한 코드에 대한 모호한 인식과 미묘한 오류로 이어집니다. 그리고 이것은 = 연산자뿐만 아니라 적어도 == 및 !=에도 적용됩니다. 그리고 아마도 다른 운영자의 경우 그러한 캐스팅을 금지해야 할 필요가 있습니다. C++에서는 +-<>[] 연산자에 적용할 수 있기 때문입니다.
간단히 말해서 평결은 다음과 같습니다. C++에서 포인터에 대해 허용되는 포인터에 연산자를 적용할 때 이 포인터를 개체에 암시적으로 캐스팅하는 것을 금지합니다. 따라서 위의 예에서는 컴파일 오류가 발생 합니다.
네, 이해할 수 있습니다. 이 간단한 예를 사용하여 포인터와 개체가 다른 개체이며 어떤 식으로든 간섭할 수 없다고 의심하는 모든 사람들을 보여주고 싶었습니다.
그리고 이 상황은 최소한 특정 스타일의 코드 작성을 의미하므로 실수로(지식이 아닌) 컴파일하고 테스트를 통과하지만 실제 조건에서 실패하는 코드를 작성하지 않으며 판매용으로 작성된 경우 훨씬 더 나쁩니다. . 모든 것이 "암시적으로" 동일한 코드에서 오류 위치를 찾는 것은 다소 어려운 작업이 될 것입니다.
모든 것이 "암시적으로" 동일한 코드에서 오류 위치를 찾는 것은 다소 어려운 작업이 될 것입니다.
개발자가 모든 것을 그대로 두는 것이 좋습니다. 이제 그들이 다시 변경되기 시작하면 언어, 많은 프로그램의 컴파일이 중지되거나 더 나쁜 경우 예상대로 작동이 중지되면 보편적인 nix가 상승할 것입니다.
내 관점에서 µl의 자동 개체는 기능이 제한된 언더 포인터(자동 삭제가 있는 상수 포인터)이며 대체로 사용해서는 안 됩니다(가비지 수집기 제외).
개발자가 모든 것을 그대로 두는 것이 좋습니다. 이제 그들이 다시 변경되기 시작하면 언어, 많은 프로그램이 컴파일을 중지하거나 더 나쁜 경우 예상대로 작동을 중지하면 보편적인 nix가 상승할 것입니다.
여기에 최소한의 변경 사항이 있습니다. 에 컴파일 규칙을 추가하기만 하면 됩니다.
그래서 그는 현재 적합하다고 여겨지는 이단을 편집하는 것을 허용하지 않습니다.
그래서 그는 현재 적합하다고 여겨지는 이단을 편집하는 것을 허용하지 않습니다.
유형 A a = 새로운 A? 또는 구체적으로) strict는 이제 모든 사람이 사용하므로 전혀 효과가 없습니다.
여기서 A 유형의 쓰기 저장이 있는 경우 a, *b = a; 런타임 오류가 발생하며, 이 경우 컴파일러는 다른 모든 유형과 마찬가지로 "초기화되지 않은 변수 'b'의 사용 가능성" 경고를 명시적으로 발행해야 합니다. 컴파일 오류 가 전혀 아닌 경우. 그러나 할당 자체 때문이 아니라 초기화되지 않은 변수에 오버로드된 함수를 사용하기 때문에 당연히 런타임 오류가 발생합니다. 이것은 정말 버그이며 과도한 코드 최적화와 관련이 있는 것 같습니다.
일반적으로 자동차를 다이노에 할당하는 데 이단은 없으며 그 반대도 마찬가지입니다. 유용한 칩이 될 수 있습니다.
그러나 나는 객체의 묵시적 복사와 같은 기능을 완전히 취소할 것입니다. With ++의 표준이기도 하지만. 사실 그 때문에 이러한 모든 문제가 발생합니다.유형 A a = 새로운 A? 또는 정확히 무엇)
글쎄, 그것은 말할 필요도 없다. 여기에 메모리 누수가 있습니다.
일반적으로 자동차를 다이노에 할당하는 데에는 이단이 없으며 그 반대의 경우도 마찬가지이며 유용한 칩이 될 수 있습니다.
네, 그냥 두세요. 하지만 분명합니다. 그리고 이것은 내 실수가 아니라 내가 필요하기 때문에 수행됩니다.
글쎄, 그것은 말할 필요도 없다. 여기에 메모리 누수가 있습니다.
글쎄, 이 누출은 순전히 당신의 잘못입니다. 왼쪽에 물체가 있다면 왜 그런 구조를 작성합니까?
그러나 반대 상황에서 포인터에 무언가를 할당하고 갑자기 역참조되면 이것은 이미 명백한 실수입니다.
여기에서 그들은 모든 것을 힙에 넣고 파리와 커틀릿을 섞었습니다. 나는 주제의 토론에 대해 이야기하고 있습니다.
왼쪽에 물체가 있다면 왜 그런 구조를 작성합니까?
인적 요소! 컴파일러는 이를 최소한으로 유지해야 합니다.
인적 요소! 컴파일러는 이를 최소한으로 유지해야 합니다.