Почему shared_ptr имеет явный конструктор

Question

Мне было интересно, почему shared_ptr не имеет неявного конструктора. Дело в том, что не это упоминается здесь: Getting a boost::shared_ptr for this

(я понял причину, но думал, что это будет весело вопрос размещать в любом случае.)

#include <boost/shared_ptr.hpp> 
#include <iostream> 

using namespace boost; 
using namespace std; 

void fun(shared_ptr<int> ptr) { 
    cout << *ptr << endl; 
} 

int main() { 
    int foo = 5; 
    fun(&foo); 
    return 0; 
} 

/* shared_ptr_test.cpp: In function `int main()': 
* shared_ptr_test.cpp:13: conversion from `int*' to non-scalar type ` 
* boost::shared_ptr<int>' requested */ 

Answer 1

В этом случае shared_ptr попытается освободить ваш стек, назначенный int. Вы не хотели бы этого, поэтому явный конструктор должен заставить вас подумать об этом.

Answer 2

Долгое время Lurker, и третий год soft eng student here, Предполагается, что Haphazard остановит вас на попытке конвертировать «естественный» указатель на shared_ptr, а затем освободить выделенный объект, не получив shared_ptr, зная о dealloc.

(Кроме того, проблемы с подсчетом вопросов blah blah).

Answer 3

int main() { 

    int foo = 5; 
    fun(&foo); 

    cout << foo << endl; // ops!! 

    return 0; 
} 

Answer 4

Я думаю, что в этом конструкторе нет причин иметь явное указание.

Упомянутые примеры с неправильным использованием оператора адреса смещения (&) не имеют смысла, поскольку в современном C++ нет возможности использовать такой оператор. За исключением только такого идиоматического кода в операторе присваивания/сравнения, как 'this == & other' и, возможно, некоторый тестовый код.

Answer 5

Логическим причина заключается в том, что:

• вызова оператора delete не подразумевается в C++
• Создание любого владеющего смарт-указатель (shared_ угодно, scoped_ угодно, ...) является действительно (отложенный) звонок оператору delete