Питання справді вкладається в заголовок: мені цікаво знати, в чому полягає технічна причина цієї різниці, а також обгрунтування?
std::shared_ptr<void> sharedToVoid; // legal;
std::unique_ptr<void> uniqueToVoid; // ill-formed;
Питання справді вкладається в заголовок: мені цікаво знати, в чому полягає технічна причина цієї різниці, а також обгрунтування?
std::shared_ptr<void> sharedToVoid; // legal;
std::unique_ptr<void> uniqueToVoid; // ill-formed;
Відповіді:
Це тому, що std::shared_ptr
реалізує стирання типів, тоді як std::unique_ptr
ні.
Оскільки std::shared_ptr
реалізовано стирання типів, воно також підтримує ще одну цікаву властивість, а саме. йому не потрібен тип видалювача як аргумент типу шаблону для шаблону класу. Подивіться на їх декларації:
template<class T,class Deleter = std::default_delete<T> >
class unique_ptr;
який має Deleter
параметр типу, а
template<class T>
class shared_ptr;
не має його.
Тепер питання полягає в тому, чому shared_ptr
виконується стирання типів? Ну, він робить це, тому що він повинен підтримувати підрахунок посилань, і щоб підтримати це, він повинен виділити пам'ять з купи, і оскільки він повинен розподілити пам'ять у будь-якому випадку, він робить ще один крок далі і реалізує стирання типів - для чого потрібна купа виділення теж. Отже, в основному це просто опортунізм!
Через стирання типу std::shared_ptr
здатний підтримувати дві речі:
void*
, проте він все ще може правильно видаляти об'єкти при знищенні , правильно викликаючи їх деструктор .Гаразд Це все про те, як std::shared_ptr
працює.
Тепер питання в тому, чи можна std::unique_ptr
зберігати об’єкти як void*
? Ну, відповідь так, за умови, що ви передаєте відповідний видаляч як аргумент. Ось одна з таких демонстрацій:
int main()
{
auto deleter = [](void const * data ) {
int const * p = static_cast<int const*>(data);
std::cout << *p << " located at " << p << " is being deleted";
delete p;
};
std::unique_ptr<void, decltype(deleter)> p(new int(959), deleter);
} //p will be deleted here, both p ;-)
Результат ( онлайн-демонстрація ):
959 located at 0x18aec20 is being deleted
Ви задали дуже цікаве питання в коментарі:
У моєму випадку мені знадобиться видаляч типів, але це теж можливо (ціною деякого розподілу купи). По суті, чи означає це, що насправді існує нішеве місце для розумного вказівника 3-го типу: ексклюзивний розумний вказівник із стиранням типу.
на що @Steve Jessop запропонував таке рішення,
Я ніколи насправді не пробував цього, але, можливо, ви могли б досягти цього, використовуючи відповідний
std::function
тип видалення зunique_ptr
? Припустимо, що насправді це працює, тоді ви закінчите, ексклюзивне право власності та видалений тип.
Слідуючи цій пропозиції, я реалізував це (хоча воно не використовує, std::function
оскільки не видається необхідним):
using unique_void_ptr = std::unique_ptr<void, void(*)(void const*)>;
template<typename T>
auto unique_void(T * ptr) -> unique_void_ptr
{
return unique_void_ptr(ptr, [](void const * data) {
T const * p = static_cast<T const*>(data);
std::cout << "{" << *p << "} located at [" << p << "] is being deleted.\n";
delete p;
});
}
int main()
{
auto p1 = unique_void(new int(959));
auto p2 = unique_void(new double(595.5));
auto p3 = unique_void(new std::string("Hello World"));
}
Результат ( онлайн-демонстрація ):
{Hello World} located at [0x2364c60] is being deleted.
{595.5} located at [0x2364c40] is being deleted.
{959} located at [0x2364c20] is being deleted.
Сподіваюся, що це допомагає.
std::function
тип видалення з unique_ptr
? Припустимо, що насправді це працює, тоді ви закінчите, ексклюзивне право власності та видалений тип.
Одне з обґрунтувань є в одному з багатьох випадків використання shared_ptr
- а саме як індикатор протягом усього життя або сторожовий.
Про це згадувалося в оригінальній документації про підвищення:
auto register_callback(std::function<void()> closure, std::shared_ptr<void> pv)
{
auto closure_target = { closure, std::weak_ptr<void>(pv) };
...
// store the target somewhere, and later....
}
void call_closure(closure_target target)
{
// test whether target of the closure still exists
auto lock = target.sentinel.lock();
if (lock) {
// if so, call the closure
target.closure();
}
}
Де closure_target
щось подібне:
struct closure_target {
std::function<void()> closure;
std::weak_ptr<void> sentinel;
};
Абонент реєструє зворотний виклик приблизно так:
struct active_object : std::enable_shared_from_this<active_object>
{
void start() {
event_emitter_.register_callback([this] { this->on_callback(); },
shared_from_this());
}
void on_callback()
{
// this is only ever called if we still exist
}
};
оскільки shared_ptr<X>
завжди є конвертованим shared_ptr<void>
, event_emitter тепер може блаженно не знати про тип об’єкта, до якого він повертається.
Ця домовленість звільняє абонентів випромінювача подій від обов'язку обробляти випадки перетину (що робити, якщо зворотний виклик потрапляє в чергу, чекаючи дії, поки active_object зникає?), А також означає, що немає необхідності синхронізувати відписку. weak_ptr<void>::lock
є синхронізованою операцією.
std::unique_ptr<void, D>
все ще можливо, надавши відповіднеD
.