Почему shared_ptr имеет явный конструктор - PullRequest
4 голосов
/ 20 ноября 2008

Мне было интересно, почему shared_ptr не имеет неявного конструктора. На это не ссылаются: Получение повышения :: shared_ptr для этого

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

#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 */

Ответы [ 5 ]

8 голосов
/ 20 ноября 2008

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

5 голосов
/ 07 октября 2011

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

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

Давний юркер, и студент 3-го курса софт англ, здесь, Случайное предположение может состоять в том, чтобы помешать вам попытаться преобразовать «естественный» указатель в shared_ptr, а затем освободить указанный объект, без того, чтобы shared_ptr знал о dealloc.

(Кроме того, проблемы с подсчетом ссылок, бла-бла).

0 голосов
/ 25 марта 2011

Я думаю, что нет никаких оснований для явного в этом конструкторе.

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

0 голосов
/ 20 ноября 2008
int main() {

    int foo = 5;
    fun(&foo);

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

    return 0;
}
...