4

I was wondering why shared_ptr doesn't have an implicit constructor. The fact it doesn't is alluded to here: Getting a boost::shared_ptr for this

(I figured out the reason but thought it would be a fun question to post anyway.)

#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 */
Improve this question
1
  • If you have the answer to the question it's fine to post it anyway. However keep the question to the question and post an answer to your question as an answer. However your answer isn't as good as the accepted answer (which is also fine). Commented Aug 6, 2024 at 7:44

5 Answers 5

Reset to default
10

In this case, the shared_ptr would attempt to free your stack allocated int. You wouldn't want that, so the explicit constructor is there to make you think about it.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

6

The logical reason is that:

  • calling the delete operator is not implicit in C++
  • the creation of any owning smart pointer (shared_whatever, scoped_whatever, ...) is really a (delayed) call to the delete operator
Improve this answer

Comments

2

Long time lurker, and a 3rd year soft eng student here, Haphazard guess would be, to stop you from attempting to convert a 'natural' pointer to a shared_ptr, then deallocing the pointed object, without the shared_ptr knowing about the dealloc.

(Also, reference counting problems blah blah).

Improve this answer

Comments

-1 
int main() { int foo = 5; fun(&foo); cout << foo << endl; // ops!! return 0; }
Improve this answer

1 Comment

I don't see how it is fundamentally different from delete &foo;
-3

I think there is no reason to have explicit in this constructor.

Mentioned examples with incorrect using of offset address operator (&) make no sense since there is no place to use such operator in modern C++. Except only such idiomatic code in assignment/comparision operator as 'this == &other' and maybe some test code.

Improve this answer

2 Comments

@vBx: in mentioned example 1 offset address operator (&) has been used to pass parameter by pointer to function. Should use reference instead.
operator& gives the address, not the "offset" (whatever that means) of a lvalue.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.