Re: Good links for handling with pointers?
* James Kanze:
On Oct 24, 2:52 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* James Kanze:
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.
I'm sorry, but that adds further invalid reasoning on top of what you
wrote earlier.
How?
That's the entirely wrong issue to focus on. Anyway, you already got an
answer to that, quoted below.
> boost::shared_ptr doesn't handle cycles.
In most of the few cases where that is an issue, a weak_ptr is an
appropriate solution to break the cyclic dependency.
Only with arbitrary dynamic sharing of substructure is a more powerful
strategy generally indicated.
You show a lack of understanding of both the technical issues and the
pedagogical ones.
You're arguing that the OP should avoid smart pointers in order to be
able to deal more easily with cycles.
No. I'm saying that boost::smart_ptr won't work when cycles are
present.
I'm sorry, that's incorrect.
It's /possible/ to write incorrect code, and cycles are indeed one case
where it's "easier" to write incorrect code than in general. Writing
incorrect code is possible regardless of use of smart pointers or not,
but it's far more likely with a novice not using smart pointers. From
the relative likelyhood of writing incorrect code in one possible case,
regardless of smart pointers or not, you're drawing the invalid
conclusion that that means it's impossible to write correct code when
using smart pointers.
Don't you see how fallacious that is?
Or perhaps you don't.
Well then, just eat the fact that it's possible to write correct code
using smart pointers, also for graphs with cycles.
Also, think about this: the OP has not stated that cycles are a problem,
or given code with cycles, or stated or indicated that the code
represents graph edges using pointers, or even stated or indicated that
the code in question deals with a graph structure, or stated or
indicated that the code given is the primary problem (in fact, the
problem was described as being of a more general nature).
It's an arbitrary possible problem you have focused on, where you could
just as well have focused on the possible problem of thread safety, or
whatever, and the solution in neither case is generally not to avoid
smart pointers.
If, as the name suggests, he's dealing with a graph of some
sort, then raw pointers are probably the easiest solution. With
garbage collection, if possible, because this is the sort or
case where garbage collection excells. Otherwise, you need some
sort of strategy to decide the lifetime of the objects;
reference counting (as used by boost::shared_ptr) *doesn't*
work.
Bull. And that doesn't mean that the opposite is always true.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?