shared_ptr как участник класса
Это характерно для заявленных содержащих в нем объектов как указатели на тот класс, в то время как "вперед declarating" их в заголовочном файле. Это для сокращения физических зависимостей в коде.
Например,
class B; // forward declaration
class A {
private:
B* pB;
};
Это была бы хорошая идея объявить такого участника как shared_ptr вместо явного указателя?
Я предпочел бы scoped_ptr, но AFAIK это это не будет в стандарте.
4 ответа
В случае композиции, да, это хорошая идея, если вы не хотите физической зависимости. Тогда ваш B будет автоматически уничтожен, когда уничтожится A.
Если вас не беспокоит физическая зависимость, вы можете просто хранить член данных по значению.
(Вы также можете проверить идиому pimpl, если физическая зависимость является проблемой)
.Если этот указатель не передан за пределы вашего класса. а скорость выполнения имеет решающее значение, используйте scoped_ptr вместо shared_ptr. shared_ptr имеет накладные расходы.
Использование shared_ptr позволит вам передать право владения другому объекту, чтобы он не был уничтожен при уничтожении вашего внешнего объекта. Вы заявляете, что в данном конкретном случае это не будет проблемой.
Единственное преимущество интеллектуального указателя состоит в том, что вам не нужно помнить о том, чтобы поместить delete pB в свой деструктор. Для большинства людей этого может быть достаточно.
Если вам не нужно беспокоиться о проблемах владения, даже auto_ptr будет достаточно.
Да, можно (нужно?).
Это обычная практика . Как вы сказали, это позволяет избежать явного вызова delete ().
Вы можете пойти еще дальше. Вот пример:
class RSAKey
{
public:
RSAKey();
private:
shared_ptr<RSA> d_rsa; // A pointer to a RSA structure from OpenSSL
}
Который я инициализирую следующим образом:
RSAKey::RSAKey()
{
RSA* rsa = RSA_generate_key(1024, 1, NULL, NULL);
if (NULL == rsa) throw DummyException();
d_rsa.reset(rsa, RSA_free); // Note the specific release method.
}
Когда d_rsa больше не будет использоваться, произойдет автоматический вызов RSA_free () . Разве это не круто ?!
Обновление
Если C ++ 11 является вариантом, вам, вероятно, лучше использовать вместо него std :: unique_ptr , который имеет меньше накладных расходов и является подвижным.
Это зависит от того, как вы хотите, чтобы ваш включающий класс вел себя в отношении копирования.