C# 표준은 다음과 같이 명시합니다. " 구조체와 같은 값 유형 개체와 클래스와 같은 참조 유형 개체는 모두 자동으로 소멸되지만 값 유형 개체는 포함하는 컨텍스트가 소멸될 때 소멸되는 반면 참조 유형 개체는 쓰레기에 의해 소멸됩니다. 마지막 참조가 제거된 후 무기한 통해 수집기 "
지금, 나는 이 "무한한 시간"을 좋아하지 않는다. 비록 가비지 컬렉터가 나 자신보다 훨씬 더 효율적으로 객체를 제거할 수 있다는 것을 인정하지만, 객체를 생성한 클래스의 소멸자에서 객체를 삭제합니다.
논리적으로 아무도 참조하지 않으므로 개체가 더 이상 누구에게도 필요하지 않으며 다음 가비지 컬렉션에서 삭제됩니다. GC에 즉시 빌드를 수행하도록 요청할 수 있지만 타이밍은 예측할 수 없습니다. 그러나 이것은 또한 명령이 아니라 요청입니다))
도입 당시에는 어떤 차이가 있습니까? 즉시 또는 한 달 후에? 당신은 그녀에 대해 몰랐고 내가 말하지 않았다면 당신은 몰랐을 것입니다)
부끄럽게 타는 게 두렵지만, fxsaber를 어디선가 보기 전까지는 &에 대해 몰랐습니다. 그렇지 않으면 GetPointer 를 사용했을 것입니다.
그러나 9월에 일부 작업에 개체를 오버로드할 수 없다는 것을 알게 되었고, 나 자신도 다른 방법으로 해결하려고 시도했고 많은 사람들이 그런 가능성이 없다고 저에게 편지를 썼습니다. 그리고 이제 그것이 사실로 밝혀졌으므로 정확히 언제 나타났는지(그리고 왜 인증서에 없는지) 궁금합니다.
잊지 않으려면 처음에 개체를 사용하는 상황과 포인터를 정확히 결정해야 합니다(이상적인 경우 개체를 사용하지 않고 항상 포인터).
자신의 코드도 열지 않고 오랜 시간(1~2년) 후에 열어서 '얇은' 곳에 주석을 남기지 않는다고 자책하고, 객체도 포인터와 구분이 안 되는 경우 일반적으로 아퉁입니다. 나는 또한 자동 개체의 거부에 동의하지 않습니다. 그것들을 사용하면 코드가 눈에 띄게 더 간결해지고 더 이상 필요하지 않은 객체의 운명을 처리합니다. 또한 컴파일러는 이러한 객체의 수명을 미리 알고 있기 때문에 동적 생성의 경우보다 최적화된 코드를 제공할 수 있다고 확신합니다.
일리야 말레프 :
그리고 이것을 위해 매번 여분의 편지를 쓰는 것(특히 괄호를 사용하여 한증탕을 하는 것)은 솔직히 바보입니다.
또한이 경우 귀하가 설명한 할당 작업은 객체와 관련하여 사용되지 않고 원칙적으로 오류 가능성을 제거하는 비 객체 필드와 관련하여 사용됩니다. 동작은 상관없음)
이 어리석음은 MQL에서 포인터로 개체에 대한 액세스를 표시할 방법이 없다는 사실에서 비롯됩니다. C/C ++에서는 물론 더 간결할 것입니다.
pA->iValue
화살표가 없는 이유는 아마도 처음에 ' * '(알 수 없음)와 같을 것입니다. 내 Qt(그리고 아마도 VS에서도)에서 편집기는 자동으로 '.' 포인터가 개체에 액세스하는 경우 '->'로 변경됩니다. 추가 제스처 0개. 원하는 경우 MQ가 편집기에 이러한 기능을 추가할 수 있다는 점에는 의심의 여지가 없습니다. 따라서 위의 예에서 포인터를 다루고 있다는 유일한 표시는 이름의 'p' 접두사뿐입니다. 그리고 내가 잊지 않았기 때문에. 모든 사람이 너무 "재치 있는" 경우 모든 것이 정상입니다))
저것들. 코드에서 잠재적으로 위험한 위치는 명확하게 표시되어야 합니다. 당신은 그들을 기억할 필요가 없습니다, 당신은 그들을 볼 필요가 있습니다. 객체와의 그러한 "관계의 공식화"에 대한 필요성은 위의 것보다 더 복잡한 예에서 더 분명할 것입니다. 예를 들어, 클래스 멤버 자체가 무언가에 대한 포인터인 경우.
POINTER_AUTOMATIC 및POINTER_DYNAMIC 작업에 대한 균일한 접근 방식을 제공함으로써 이러한 포인터 유형의 유사성에 대한 잘못된 인상을 줍니다. 그러나 사실 이들은 서로 다른 실체이며 다른 태도를 요구합니다.이것은 스레드의 주요 주제입니다.물론 가장 분명한 사실은POINTER_AUTOMATIC이 항상 실제 개체를 가리키는 경우 POINTER_DYNAMIC도 비어 있을 수 있다는 점입니다.
그리고 모든 종류의 데이터 액세스 변형(경로가 일치하는 한 C/C ++ 포함)을 상기시켜 드리겠습니다.
MKL에서 모든 것이 분명히 C ++에서와 같지 않다는 것입니다. 여기서 포인터는 별도의 데이터 유형 이 아니므로 둘 다 객체이고 핸들이 변수에 있습니다. 동시에 변수에는 숨겨진 속성인 불변성이 있지만(* 없이 선언된 경우) 이것이 본질적으로 다른 유형의 변수가 되는 것은 아니며 다른 핸들을 할당하는 것을 금지할 뿐입니다.
아니요. 이 경우 블록을 종료할 때 변수를 삭제해야 합니다.
new에 의해 생성된 객체에 대해 이야기하고 있습니다.
C# 표준은 다음과 같이 명시합니다. " 구조체와 같은 값 유형 개체와 클래스와 같은 참조 유형 개체는 모두 자동으로 소멸되지만 값 유형 개체는 포함하는 컨텍스트가 소멸될 때 소멸되는 반면 참조 유형 개체는 쓰레기에 의해 소멸됩니다. 마지막 참조가 제거된 후 무기한 통해 수집기 "
지금, 나는 이 "무한한 시간"을 좋아하지 않는다. 비록 가비지 컬렉터가 나 자신보다 훨씬 더 효율적으로 객체를 제거할 수 있다는 것을 인정하지만, 객체를 생성한 클래스의 소멸자에서 객체를 삭제합니다.
논리적으로 아무도 참조하지 않으므로 개체가 더 이상 누구에게도 필요하지 않으며 다음 가비지 컬렉션에서 삭제됩니다. GC에 즉시 빌드를 수행하도록 요청할 수 있지만 타이밍은 예측할 수 없습니다. 그러나 이것은 또한 명령이 아니라 요청입니다))
따라서 가비지 수집기가 라이브 개체나 포인터를 삭제할 것이라는 말은 아닙니다. 그가 원할 때 그것을 지울 것이라는 사실에 대해 말하는 것입니다.
샤프는 객체가 가비지 수집기에 의해 삭제되지 않도록 보호하는 기능을 제공합니다.
https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.gchandle.alloc?view=netcore-2.0
그리고 이제 당신은 왜 그것을 몰랐는지 필사적으로 변명하기 시작합니다 ;)
도입 당시에는 어떤 차이가 있습니까? 즉시 또는 한 달 후에? 당신은 그녀에 대해 몰랐고 내가 말하지 않았다면 당신은 몰랐을 것입니다)
부끄럽게 타는 게 두렵지만, fxsaber를 어디선가 보기 전까지는 &에 대해 몰랐습니다. 그렇지 않으면 GetPointer 를 사용했을 것입니다.
그러나 9월에 일부 작업에 개체를 오버로드할 수 없다는 것을 알게 되었고, 나 자신도 다른 방법으로 해결하려고 시도했고 많은 사람들이 그런 가능성이 없다고 저에게 편지를 썼습니다. 그리고 이제 그것이 사실로 밝혀졌으므로 정확히 언제 나타났는지(그리고 왜 인증서에 없는지) 궁금합니다.
아마도 그들은 여전히 "관리 코드"에 포인터가 없고 모든 것이 객체이며 단순한 유형이더라도 bool int double 등인 C#의 방향으로 갈 것입니다.
나쁘지는 않겠지만 이 방향으로 아무것도 바꾸지 않을 가능성이 높기 때문입니다. 이것은 터미널 언어 개념의 완전한 변경이며 거의 수행되지 않습니다.
여기에서 IMHO에 따르면 이것은 정확히 무엇을 다루고 있는지(객체 또는 객체에 대한 포인터) 잊지 않기 위해 필요합니다.
잊지 않으려면 처음에 개체를 사용하는 상황과 포인터를 정확히 결정해야 합니다(이상적인 경우 개체를 사용하지 않고 항상 포인터).
그리고 이것을 위해 매번 여분의 편지를 쓰는 것(특히 괄호를 사용하여 한증탕을 하는 것)은 솔직히 바보입니다.
또한이 경우 귀하가 설명한 할당 작업은 객체와 관련하여 사용되지 않고 원칙적으로 오류 가능성을 제거하는 비 객체 필드와 관련하여 사용됩니다. 동작은 상관없음)
잊지 않으려면 처음에 개체를 사용하는 상황과 포인터를 정확히 결정해야 합니다(이상적인 경우 개체를 사용하지 않고 항상 포인터).
자신의 코드도 열지 않고 오랜 시간(1~2년) 후에 열어서 '얇은' 곳에 주석을 남기지 않는다고 자책하고, 객체도 포인터와 구분이 안 되는 경우 일반적으로 아퉁입니다. 나는 또한 자동 개체의 거부에 동의하지 않습니다. 그것들을 사용하면 코드가 눈에 띄게 더 간결해지고 더 이상 필요하지 않은 객체의 운명을 처리합니다. 또한 컴파일러는 이러한 객체의 수명을 미리 알고 있기 때문에 동적 생성의 경우보다 최적화된 코드를 제공할 수 있다고 확신합니다.
그리고 이것을 위해 매번 여분의 편지를 쓰는 것(특히 괄호를 사용하여 한증탕을 하는 것)은 솔직히 바보입니다.
또한이 경우 귀하가 설명한 할당 작업은 객체와 관련하여 사용되지 않고 원칙적으로 오류 가능성을 제거하는 비 객체 필드와 관련하여 사용됩니다. 동작은 상관없음)
이 어리석음은 MQL에서 포인터로 개체에 대한 액세스를 표시할 방법이 없다는 사실에서 비롯됩니다. C/C ++에서는 물론 더 간결할 것입니다.
화살표가 없는 이유는 아마도 처음에 ' * '(알 수 없음)와 같을 것입니다. 내 Qt(그리고 아마도 VS에서도)에서 편집기는 자동으로 '.' 포인터가 개체에 액세스하는 경우 '->'로 변경됩니다. 추가 제스처 0개. 원하는 경우 MQ가 편집기에 이러한 기능을 추가할 수 있다는 점에는 의심의 여지가 없습니다. 따라서 위의 예에서 포인터를 다루고 있다는 유일한 표시는 이름의 'p' 접두사뿐입니다. 그리고 내가 잊지 않았기 때문에. 모든 사람이 너무 "재치 있는" 경우 모든 것이 정상입니다))
저것들. 코드에서 잠재적으로 위험한 위치는 명확하게 표시되어야 합니다. 당신은 그들을 기억할 필요가 없습니다, 당신은 그들을 볼 필요가 있습니다. 객체와의 그러한 "관계의 공식화"에 대한 필요성은 위의 것보다 더 복잡한 예에서 더 분명할 것입니다. 예를 들어, 클래스 멤버 자체가 무언가에 대한 포인터인 경우.
POINTER_AUTOMATIC 및 POINTER_DYNAMIC 작업에 대한 균일한 접근 방식을 제공함으로써 이러한 포인터 유형의 유사성에 대한 잘못된 인상을 줍니다. 그러나 사실 이들은 서로 다른 실체이며 다른 태도를 요구합니다. 이것은 스레드의 주요 주제입니다. 물론 가장 분명한 사실은 POINTER_AUTOMATIC이 항상 실제 개체를 가리키는 경우 POINTER_DYNAMIC 도 비어 있을 수 있다는 점 입니다.
그리고 모든 종류의 데이터 액세스 변형(경로가 일치하는 한 C/C ++ 포함)을 상기시켜 드리겠습니다.
물론 가장 분명한 사실은 POINTER_AUTOMATIC이 항상 실제 개체를 가리키는 경우 POINTER_DYNAMIC 도 비어 있을 수 있다는 점 입니다.
"가장 명백한"이 이미 거짓이라면 다른 모든 것을 진지하게 고려하고 대답할 가치가 있습니까?
POINTER_AUTOMATIC 은 변수 유형이 아니라 상태입니다. 다음 순간 그녀의 상태는 완전히 다를 수 있습니다. 물론 POINTER_INVALID 포함"가장 명백한"이 이미 거짓이라면 다른 모든 것을 진지하게 고려하고 대답할 가치가 있습니까?
가능하다면 이에 대한 설명을 듣고 싶습니다.
POINTER_AUTOMATIC 은 변수 유형이 아니라 상태입니다. 다음 순간 그녀의 상태 는 완전히 다를 수 있습니다.
물론 유형은 아닙니다. 저것들. 예를 들어 autoobject는 상태가 POINTER_DYNAMIC인 포인터가 됩니까? 물론 예를 들어 포인터를 선언할 때 POINTER_INVALID 상태를 의미했습니다.
가능하다면 이에 대한 설명을 듣고 싶습니다.
MKL에서 모든 것이 분명히 C ++에서와 같지 않다는 것입니다. 여기서 포인터는 별도의 데이터 유형 이 아니므로 둘 다 객체이고 핸들이 변수에 있습니다. 동시에 변수에는 숨겨진 속성인 불변성이 있지만(* 없이 선언된 경우) 이것이 본질적으로 다른 유형의 변수가 되는 것은 아니며 다른 핸들을 할당하는 것을 금지할 뿐입니다.
즉, 선언
그리고 당신은 정확히 동일한 "자동 개체"를 갖게 될 것이며, 당신 자신만이 그것을 삭제할 것입니다.