C ++ / CLI обмениваются ссылками на объекты между несколькими gcrooted управляемыми объектами

Question

Привет, к сожалению, я не очень хорош во всем этом.Теперь я не уверен, что у меня возникнут проблемы, если я сделаю следующее:

// unmanaged Class
class CUnmagedClass : public CCmdTarget
{
    auto_gcroot<Dictionary<int, System::String^>^> m_dict;
    auto_gcroot<SomeManagedClass^> m_managedClass;

    // create first manage object in one gcroot
    CUnmagedClass()
    :dict(gcnew Dictionary<LANGID, System::String^>())
    {}

    // do something with the dictionary
    void AddData(int key, String^ value)
    {
         this->m_dict->Add(key, value);
    }

    // Method that could be called multiple times
    void DoOtherThings(Data^ data)
    {
         // create a new object on every method call
         // old object can be garbage collected
         this->m_managedClass = gcnew SomeManagedClass(data);
         // assign a reference to the dictionary from the other gcroot
         this->m_managedClass->DictProp = this->m_dict;

         this->m_managedClass->DoSomething();
    }

}

Поэтому мой вопрос: перезаписать ли значение в this->m_managedClass и старшее SomeManagedClassЭкземпляр является сборщиком мусора.Система пытается также собрать объект в this->m_managedClass->DictProp, потому что он больше не подключен ко второму gcroot или сборщик мусора достаточно умен, чтобы знать, что в другом gcroot?

осталась ссылка

Answer 1

Система также не будет пытаться собрать this->m_managedClass->DictProp, потому что она достаточно умна, чтобы знать, что на этот объект ссылаются другие gcroot.

Причина, по которой gcroot такой умный, заключается вон оборачивает System::Runtime::InteropServices::GCHandle, который является ручкой в ​​кучу мусора.Класс GCHandle - это то, что позволяет вашему неуправляемому объекту хранить то, что фактически является управляемой ссылкой.Кроме того, даже если ваш управляемый объект перемещен сборщиком мусора, ссылка GCHandle будет обновлена, чтобы указать ее новое местоположение.