사실, CArray의 클래스-후계자는 나에게 매우 편리합니다. 배열에 대한 포인터를 원하는 유일한 것은 배열에 대한 참조가 전달되는 표시기이며 개체의 전체 계층 구조를 통해 이러한 참조를 "끌어야" 합니다. 이는 매우 불편합니다...
일단 내가 배열에 대한 포인터를 만들거나 배열에 대한 참조가 아니라 표준 라이브러리 의 배열에 대한 포인터를 사용하는 표시기 기능을 만들 것을 제안했지만, 슬프게도 나는 거절당했습니다. "만약 배열에 대한 포인터를 허용하면 초기화되지 않은 배열을 사용할 수 있습니다." 개발자는 객체에 대해 그런 걱정을 하지 않습니다. 글쎄요, 그렇습니다.
따라서 가비지 수집기가 라이브 개체나 포인터를 삭제할 것이라는 말은 아닙니다. 그가 원할 때 그것을 지울 것이라는 사실에 대해 말하는 것입니다. 그리고 이것은 제 생각에는 좋지 않습니다.
제거하거나 제거하지 않고 작업할 수 있습니다. 그리고 스마트포인터도 죽일 수 있는데.. 그래도 객체는 지워야 하고, 만든 사람은 객체를 지워야 한다고 생각합니다.
나는 그런 구식의 골화 된 방귀입니다.
조르쥬, 당신이 예를 들어줄 수 있어요, 당신을 이해하지 못합니다. 이게 네가 말하는거야? 스마트 포인터를 직접 만들 수도 있습니다.
bool first = false ;
int Foo()
{
int i;
if (!first)
{
first = true ;
i = 123 ;
}
return i;
}
// И ты будешь надеятся, что i сохранит свое значение между сотней вызовов Foo? Может да (очень редко, если Foo вызывается 100 раз подряд), а может и нет.
조르쥬, 당신이 예를 들어줄 수 있습니다, 당신을 이해하지 못합니다. 이게 네가 말하는거야? 스마트 포인터를 직접 만들 수도 있습니다.
아니요. 이 경우 블록을 종료할 때 변수를 삭제해야 합니다.
new에 의해 생성된 객체에 대해 이야기하고 있습니다.
CMyObj* pmoObject = new CMyObject;
C# 표준은 다음과 같이 명시합니다. " 구조체와 같은 값 유형 개체와 클래스와 같은 참조 유형 개체는 모두 자동으로 소멸되지만 값 유형 개체는 포함하는 컨텍스트가 소멸될 때 소멸되는 반면 참조 유형 개체는 쓰레기에 의해 소멸됩니다. 마지막 참조가 제거된 후 무기한 통해 수집기 "
지금, 나는 이 "무한한 시간"을 좋아하지 않는다. 비록 가비지 컬렉터가 나 자신보다 훨씬 더 효율적으로 객체를 제거할 수 있다는 것을 인정하지만, 객체를 생성한 클래스의 소멸자에서 객체를 삭제합니다.
여기 있습니다: (* ) 여기에 필요하지 않습니다
* =, ==, !=, !, && 또는 ||인 경우에만 µl에 필요여기에서 IMHO에 따르면 이것은 정확히 무엇을 다루고 있는지(객체 또는 객체에 대한 포인터) 잊지 않기 위해 필요합니다.
그것을 다시 제거하고 거기에 없는 척하십시오))))
네. 포인터를 사용한 추가 개발은 C++의 완전한 복제로 이어질 것입니다.
아마도 그들은 여전히 "관리 코드"에 포인터가 없고 모든 것이 객체이며 단순한 유형이더라도 bool int double 등인 C#의 방향으로 갈 것입니다.
그러나 그건 그렇고, 운영자에 대한 모든 공식 채널 (포럼, 도움말, 문서) * 치명적인 침묵 때문에 아마도 관리자는 그를 다시 제거하고 그가 아닌 척하는 것에 대해 생각하고있을 것입니다. ))) 따라서 지금까지 IMHO를 사용하는 것은 일반적으로 위험합니다.
침묵은 아마도 사용자의 99.9%에게 이 모든 것이 중요하지 않기 때문일 것입니다. 왜 불필요한 정보로 그들의 사교를 긴장시키십니까? 그리고 이 기능이 필요한 사람들이 요청해서 얻었습니다.
그나저나 너도 지금까지 이 기능 신경 안썼지? 그리고 지금 당신은 왜 그것에 대해 몰랐는지 필사적으로 변명하기 시작했습니다.) 그것이 도입되었을 때 어떤 차이가 있습니까? 즉시 또는 한 달 후에? 당신은 그녀에 대해 몰랐고 내가 말하지 않았다면 당신은 몰랐을 것입니다)
흠... 배열에 대한 포인터가 있습니까? 확인해야지... 너무 보고싶어...
흠... 배열에 대한 포인터가 있습니까? 확인해야지... 너무 보고싶어...
아니요. 포인터가 있는 클래스에 배열을 넣어야 합니다.
아니요. 포인터가 있는 클래스에 배열을 넣어야 합니다.
예, 아아.
사실, CArray의 클래스-후계자는 나에게 매우 편리합니다. 배열에 대한 포인터를 원하는 유일한 것은 배열에 대한 참조가 전달되는 표시기이며 개체의 전체 계층 구조를 통해 이러한 참조를 "끌어야" 합니다. 이는 매우 불편합니다...
일단 내가 배열에 대한 포인터를 만들거나 배열에 대한 참조가 아니라 표준 라이브러리 의 배열에 대한 포인터를 사용하는 표시기 기능을 만들 것을 제안했지만, 슬프게도 나는 거절당했습니다. "만약 배열에 대한 포인터를 허용하면 초기화되지 않은 배열을 사용할 수 있습니다." 개발자는 객체에 대해 그런 걱정을 하지 않습니다. 글쎄요, 그렇습니다.
2. MQL은 선택하지 않은 것을 제거해서는 안 됩니다. 사실, Dmitry는 위에서 개체를 생성했다고 말했습니다. 삭제합니다. 나는 객체가 내가 제공했을 때가 아니라 수집기가 원할 때 삭제 되는 동일한 C#에서 "가비지 수집기"의 관행을 정말 싫어합니다.
C# 수집기는 라이브 개체 또는 포인터를 삭제하지 않습니다. 그 목적은 힙에서 시체에서 쓰레기를 제거하고 때로는 조각 모음을 수행하는 것입니다.
C# 수집기는 라이브 개체 또는 포인터를 삭제하지 않습니다. 그 목적은 힙에서 시체에서 쓰레기를 제거하고 때로는 조각 모음을 수행하는 것입니다.
따라서 가비지 수집기가 라이브 개체나 포인터를 삭제할 것이라는 말은 아닙니다. 그가 원할 때 그것을 지울 것이라는 사실에 대해 말하는 것입니다. 그리고 이것은 제 생각에는 좋지 않습니다.
제거하거나 제거하지 않고 작업할 수 있습니다. 그리고 스마트포인터도 죽일 수 있는데... 그래도 객체는 삭제가 있어야 하고, 생성한 사람은 객체를 삭제해야 한다고 생각합니다.
나는 그런 구식의 골화 된 방귀입니다.
아마도 그들은 여전히 "관리 코드"에 포인터가 없고 모든 것이 객체이며 단순한 유형이더라도 bool int double 등인 C#의 방향으로 갈 것입니다.
예, 하지만 동시에 관리되지 않는 포인터로 작업할 수 있는 기능을 남겼습니다. 사실, 그러한 코드는 배포에 제한이 있습니다.
따라서 가비지 수집기가 라이브 개체나 포인터를 삭제할 것이라는 말은 아닙니다. 그가 원할 때 그것을 지울 것이라는 사실에 대해 말하는 것입니다. 그리고 이것은 제 생각에는 좋지 않습니다.
제거하거나 제거하지 않고 작업할 수 있습니다. 그리고 스마트포인터도 죽일 수 있는데.. 그래도 객체는 지워야 하고, 만든 사람은 객체를 지워야 한다고 생각합니다.
나는 그런 구식의 골화 된 방귀입니다.
조르쥬, 당신이 예를 들어줄 수 있어요, 당신을 이해하지 못합니다. 이게 네가 말하는거야? 스마트 포인터를 직접 만들 수도 있습니다.
조르쥬, 당신이 예를 들어줄 수 있습니다, 당신을 이해하지 못합니다. 이게 네가 말하는거야? 스마트 포인터를 직접 만들 수도 있습니다.
아니요. 이 경우 블록을 종료할 때 변수를 삭제해야 합니다.
new에 의해 생성된 객체에 대해 이야기하고 있습니다.
CMyObj* pmoObject = new CMyObject;C# 표준은 다음과 같이 명시합니다. " 구조체와 같은 값 유형 개체와 클래스와 같은 참조 유형 개체는 모두 자동으로 소멸되지만 값 유형 개체는 포함하는 컨텍스트가 소멸될 때 소멸되는 반면 참조 유형 개체는 쓰레기에 의해 소멸됩니다. 마지막 참조가 제거된 후 무기한 통해 수집기 "
지금, 나는 이 "무한한 시간"을 좋아하지 않는다. 비록 가비지 컬렉터가 나 자신보다 훨씬 더 효율적으로 객체를 제거할 수 있다는 것을 인정하지만, 객체를 생성한 클래스의 소멸자에서 객체를 삭제합니다.