[boost] Re: Dangerous smart pointers? (Was: Bogus smart pointers?)

From: Marco Manfredini (marco_at_[hidden])
Date: 2000-03-09 14:50:51

> -----Original Message-----
> From: bonnard_at_[hidden]
> [mailto:bonnard_at_[hidden]]On Behalf Of
> Valentin Bonnard
> Sent: Thursday, March 09, 2000 4:58 PM
> To: boost_at_[hidden]
> Subject: [boost] Re: Dangerous smart pointers? (Was: Bogus smart
> pointers?)
>
...
>
>
> I feel that the issue is to teach people to read the doc.
>
> The doc of _ptr is quite explicit about what _ptr does and
> doesn't do. In particular, constructing a _ptr with a raw
> pointer *always takes ownership*.
>

I think the docs should mention the issue of the unsecured 'this' pointer
during a call.

> It's a simple fact that giving away what you don't own is a
> steal. Constructing a _ptr from a raw pointer you aren't
> responsible to delete is wrong.
>

Probably this makes non-intrusive smart pointer very instrusive to the code.

>Indeed it is possible to detect such cases: all we need is a
>global database of objects owned by _ptr. Then, when a _ptr is
>initialised with a raw pointer, it could check in the database
>to see if the object is already owned. Then it could either
>shared the object with the existing owner or throw an exception...
>...
>I don't see _any_ reasons to do so and annoy every user for
>some sloppy programmers. Initialising an owning smart-ptr with
>a pointer we don't own is not a practice we want to promote.

This does not mean, that it should compile and crash _somewhere_, just to
punish the programmer for his sloppyness. I think, the ability to detect
illegal initializations either in compile- or runtime is important.

> ...
> When a function foo (T* p) called, foo can expect
> the pointer p to remain valid for the duration of
> the function or until foo deletes p (unless otherwise
> specified in the interface of the function).
> The function does not have to manipulate any smart pointer
> for this purpose, this is a fundamental guaranty.

The Code showed, that it can't.

> If a member function ``commits suicide'' (that is, delete this),
> it should understand the consequences.
>

The member function wasn't commiting suicide. The member called code, that
killed an active object. In "reality" it means, an member calls code, that
calls code, that calls code...that kills an active object. And that's a
problem that can't be adresses with scoped_ptr yet. Making a temporary is a
workaround, but it hides the motivation for the temporary -- and hiding the
motivation to do something is one path to sloppyness.
Anyway: everyone in the example played by the rules and troubles came from
the fact, that the user of an object is not always the owner.

> Short answer: this is a non-problem, and we aren't going
>               to break working code to solve it.
>
Dunno

Greetings
-Marco