|
Boost : |
From: James Kanze (kanze_at_[hidden])
Date: 2002-04-08 01:13:02
"E. Gladyshev" <egladysh_at_[hidden]> writes:
|> I've decided to start another thread, since my original "plain
|> pointers and shared_ptr" caused some confusion.
|> To understand what I was talking about, here is a puzzle :).
|> Objective:
|> implement a smart pointer
|> shared_pointer<int> and function foo( int* px )
|> that does something on *px. foo() can
|> use shared_pointer<int> but only internally.
Can you present any realistic case where this is a reasonable objective?
In theory, the rule is simple: if smart pointers are used, only smart
pointers should be used. If an object is owned by a shared_ptr, there
should be no raw pointers to it, or the program is broken.
In practice, this rule cannot be applied for several reasons:
- Typical smart_ptr implementations cannot handle cycles, so some sort
of raw pointer is introduced to prevent them.
- Legacy libraries require raw pointers (or worse, some different type
of smart pointer).
- I've yet to find a way to make "this" a smart pointer.
The first reason rarely creates problems, although it does mean that a
lot more thought is necessary. The second generally requires ad hoc
solutions; whatever you do most conform to the rules of the legacy
library, and it is very unlikely that any standard smart pointer will
help here. The third simply means that you must be able to create a
smart pointer several times from a raw pointer, or the smart pointer is,
for all pratical purposes, useless, at least as a general solution.
-- James Kanze mailto:kanze_at_[hidden] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(0)179 2607481
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk