Re: Good links for handling with pointers?
On Oct 23, 2:12 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
On Oct 22, 2:41 pm, "Alf P. Steinbach" <al...@start.no> wrote:
[...]
Use boost::shared_ptr instead of raw pointers.
That's bad advice, generally. There are cases where
boost::shared_ptr is appropriate, but there are lots of cases
where it isn't. Expecting it to solve all of your problems will
only lead to more problems.
Sorry James, that's stupid.
Nobody's expected shared_ptr to solve all your problems.
It's very very very bad advice you're giving here.
Your statement, as it stands is bad advice. shared_ptr won't
solve his problem here. Judging from the name of the type
(Knoten), it will probably get him into deeper problems.
(Knoten suggests some sort of graph, which in turn suggests the
possibility of cycles.
In context, however: it's not clear from the context whether you
meant use shared_ptr instead of raw pointer as a general rule
(it's a bad one), or simply in this application (it's probably a
bad rule here as well, if Knoten means "node", as it usually
does in German), or simply in the array (and no where else). If
I misunderstood what you meant (it seemed clear when I read it
yesterday, but not so much today), I'm sorry.
Depending on the rest of the application (which we don't really
know), it might make sense to use shared_ptr in the array. But
I'll admit that I don't really follow the rest of his code that
well: "nodes", in all of the graph algorithms I know, are
manipulated by pointers, and are not copiable, but he later uses
pass by value. If by Knoten, he means something different than
the classical node in a graph, something with value semantics,
then the array should be of Knoten, and not any pointer type:
smart or raw. If Knoten doesn't have value semantics, on the
other hand, he should inhibit copy and assignment, and use
pointers everywhere. Probably raw pointers, at least most of
the time, but it's possible to arrange for all nodes to be in
some sort of "owning" vector, and use shared_ptr in it. (In
practice, of course, in most applications, shared_ptr has very
little use. Pointers to objects with value semantics are rare,
and entity objects generally manage their own lifetime, so the
use of shared_ptr is limited to a few special
cases---polymorphic agents and the like.)
[...]
Instead, what you probably need most is to discover that the standard
library's collection classes solve most of the problems you're
struggling with.
Some pointer usage will remain.
And most of it will be navigation. Where boost::shared_ptr
isn't appropriate.
For that, use smart pointers such as boost::shared_ptr so that
you don't have to struggle with deallocation and invalid
pointers and so on.
If the only problem is deallocation, the Boehm garbage collector
is a much simpler solution than boost::shared_ptr.
I know you're using that, but you're the only person I know of
who does.
I use it because I'm in the business of producing reliable
software at the lowest cost possible. Any tool which reduces my
work load is good. But don't get me wrong. It's just one tool
of many, and it's not always applicable. (Getting legacy code
or third party libraries to work correctly with it isn't always
trivial.) And it's importance is considerably less than in
languages that don't have full support for value semantics; as I
said above, most objects in a C++ application either have value
semantics (and so aren't allocated dynamically to begin with),
or manage their own lifetime (in which case, garbage collection
is only a safety net). With or without it, however, I don't use
boost::shared_ptr very much.
[snip]
Just systematically replacing all raw pointers with
boost::shared_ptr, however, is almost guaranteed to get you into
trouble.
That would be stupid, yes.
Similarly stupid, just replacing all deallocation with the Boehm
collector would be almost guaranteed to get you into trouble.
All deallocation, no. But you still have to call some
destructors at a deterministic moment.
The real difference is that garbage collection separates memory
management from object lifetime. You still have to be concerned
with object lifetime. At the present state of the art, I don't
think any tool can relieve you of object lifetime
considerations; they're a design issue, and currently, I know of
no tool which can automatically handle design. What garbage
collection does is 1) ensures that the memory of a dead
(destructed) object doesn't get used for anything else as long
as there is a reachable pointer to it, so you can easily detect
the use of a dead object, and recognize it as such, and 2)
relieves you of the *implementation* details of objects for
which there is no significant activity at the end of lifetime
(typically, polymorphic agents and the like). boost::shared_ptr
is a very viable alternative in the second case; in the first,
it is somewhat more difficult to use because most of the
pointers involved are for navigation, with the result that there
are cycles which have to be broken.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34