2017-10-07 5 views
1

감사합니다. 저는 VS2013 코드에 익숙합니다.이 코드는 C++과 Microsoft의 특정 확장을 혼합 한 것입니다.)관리되지 않는/관리되지 않는 멤버를 관리되는 클래스에 추가

1 : 코드는

ref class Foo { 
    Bar^ bar_; // somewhere else, bar_ = gcnew Bar... 
}; 

같은 클래스가 지금은 내가

ref class Foo { 
    Bar^bar_; 
    Unmanaged* ptr_; // somewhere else, ptr = new Unmanaged(); 
    ~Foo() { 
     this->!Foo(); 
    } 
    !Foo() { 
     delete ptr_; 
     // do I need anything to deal with bar_? 
    } 
}; 

을 질문 할 수있는 것 같다 온라인 검색에서 관리되지 않는 구성원을 추가해야 할 것있다 이 파이널 라이저/소멸자가가는 길인가?

2) finalizer/destructor를 명시 적으로 작성 했으므로 bar_에 대한 추가 내용을 작성해야합니까?

3) 더 깨끗한 방법이 있습니까?

답변

3

1)이 마무리 자/소멸자 가야 할 길은 무엇입니까?

예.

2) 내가 bar_의 조각에서 분명하다

아무것도 여분의 아무것도 쓸 필요합니까. 하지만 Bar 클래스가 일회용으로 사용된다면 소멸자에 delete bar_;을 추가해야 할 것입니다. 최종 결정자가 아니야. 그리고 다른 코드에 대한 참조를 전달하지 않아서이 참조가 여전히 Bar 객체를 사용하는 마지막 참조인지 확신 할 수 없습니다.

3) 더 깨끗한 방법이 있습니까?

아니요. 기타 수 있습니다. 예를 들어 소멸자를 추가하지 않을 수도 있습니다. 클래스를 사용하면 클래스를 호출하는 부담을 갖게됩니다. 일반적으로 C# 또는 VB.NET 코드 일 경우 using 문을 사용하거나 Dispose()를 명시 적으로 호출해야합니다. 그들은 종종 잊는다는 것을 명심하십시오. 아니면 전화 할 좋은 방법이 없습니다.

그런 코드가 Foo 인스턴스를 많이 생성 할 것으로 예상되지 않고 Unmanaged 클래스가 메모리의 일부만 사용하면 finalizer가 충분히 좋을 수도 있습니다. 또는 Foo 객체가 앱의 평생 동안 유지 될 것으로 예상되는 경우, 매우 일반적이어서 삭제는 무의미합니다. 그것이 많은 메모리를 사용하더라도 GC :: AddMemoryPressure()는 꽤 좋은 대안이다. 수업을보다 사용하기 쉽게 만듭니다.

그리고 Foo가 파이널 라이저를 더 이상 필요로하지 않도록 관리되지 않는 포인터를 자체 클래스로 래핑하는 것을 고려할 수 있습니다. .NET의 SafeHandle 클래스 패턴에 따라 SafeBuffer가 가장 비슷합니다. 그러나 C++/CLI 래퍼에서 특히 과도한 경향이 있습니다. delete 오류는 특히 숨길 필요가 없습니다.

하지만 당신이 가진 일은 끝났습니다.

+0

감사합니다. @ hans-passant! 순수한 C++ 이었지만 VS2013을 처음 접했으니 한 번 더 후속 조치를 취하십시오. 수업이 일회용인지 어떻게 확인합니까? 그들은 모두 선언문에서 분명합니까? 또한 POD ('bool' 등), 배열 ^','String ^'과 같은 것들도 보았습니다. 예를 들어'ref class array'의 소스에 접근 할 수 없습니까? – hahaha

+1

IDisposable 인터페이스를 구현할 때. 개체 브라우저는 말할 수 있습니다. 포드는 절대하지 않습니다. –

관련 문제