c++ - Por qué shared_ptr tiene un constructor explícito

boost refcounting

Question

Me preguntaba por qué shared_ptr no tiene un constructor implícito. El hecho de que no se alude aquí: obtener un impulso :: shared_ptr para esto

(Descubrí el motivo pero pensé que sería una pregunta divertida para publicar de todos modos).

#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

En este caso, shared_ptr intentará liberar su pila asignada int. No querrás eso, entonces el constructor explícito está ahí para hacerte pensar sobre eso.

Answer 2

Hace mucho tiempo que lurker, y un estudiante de tercer año de eng suave aquí, Haphazard supondría, para evitar que intentes convertir un puntero "natural" a un shared_ptr, luego desasignar el objeto puntiagudo, sin que shared_ptr sepa sobre el dealloc.

(También, problemas de conteo de referencias, bla, bla).

Answer 3

int main() {

    int foo = 5;
    fun(&foo);

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

    return 0;
}

Answer 4

Creo que no hay ninguna razón para tener explícito en este constructor.

Los ejemplos mencionados con uso incorrecto del operador de dirección de desplazamiento (&) no tienen sentido ya que no hay lugar para usar dicho operador en C ++ moderno. Excepto solo el código idiomático en el operador de asignación / comparación como ''this == & other'' y tal vez algún código de prueba.

Answer 5

La razón lógica es que:

• llamar al operador de delete no está implícito en C ++
• la creación de cualquier puntero inteligente propietario ( shared_ whatever, scoped_ whatever, ...) es realmente una llamada (demorada) al operador delete