Re: delete a pointer
On 13 May, 11:28, =D6=F6 Tiib <oot...@hot.ee> wrote:
On May 13, 2:00 am, James Kanze <james.ka...@gmail.com> wrote:
On May 11, 9:45 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
On 11 mai, 20:12, James Kanze <james.ka...@gmail.com> wrote:
On May 9, 4:08 pm, =D6=F6 Tiib <oot...@hot.ee> wrote:
[...]
Ban the unary & operator, and use garbage collection, and
it's fairly easy. But that first one can sometimes be a
very awkward restriction.
I can sometimes live without & operator, but garbage
collection does not often suit me.
It depends on what you're doing, and what you want garbage
collection to do.
Actually i perhaps tried GC too many years ago and something
is changed there. I found myself explicitily deallocating
everything there was. As debugging tool to detect memory
leaks it was a bit too expensive and jumpy.
It is important to control exactly when some things are
destroyed (because of the precious contents these have).
Which is independent of garbage collection. Except that
garbage collection can be used to ensure that any access to
the object after you've destroyed it causes an immediate
program failure, rather than random behavior.
OK, now that sounds very good. I must ensure that there are no
such things. Write access check i already have but it is
debug/test time check. Does it really work with read access
too? The one that i tried was not certainly ensuring that.
It's not that automatic. It works because you only access (read
or write) through member functions, and the member functions all
start with a validation check, that the object is still good.
For this to work, however, you have to ensure that the memory
doesn't get reallocated, since if it does, the next user might
put something that looks valid where you'd written something
easily recognizable as invalid.
For some whim of fate the objects with precious contents
tend to be also the ones whose reference more than one
other object needs to know. Relying on garbage collection
leads to two-phase destruction or additional wrapper layer
and all the code bloat that it causes.
I don't follow you there. Garbage collection has no
influence as to when the object is destroyed. The two
issues are (or should be) orthogonal.
Yes. So i have to track down and reset or kill all the
pointers too. (To achieve it I may signal to the pointers or
make pointers to observe the object.)
Generally, yes. Forgetting to do so is a frequent cause of
leaked memory.
What i do. So i do not see how garbage collection helps me,
unless i use two layers or phases of destruction.
I don't understand what you mean by two layers or phases of
destruction.
Garbage collection helps by ensuring that the memory cannot be
reused as long as anyone has a pointer to it.
Reference counting is more helpful since it lets to hunt down
the references and reset them when precious things must to be
released.
Again, I don't follow you. Most of the time, reference counting
is used as a slow and slightly broken form of garbage
collection.
I use reference counting like pointers with run-time debugging
attached. One should know how to reach everybody who have the
reference to object under axe so if reaching them did fail
then there is a bug.
But reference counting doesn't help in reaching everybody.
--
James Kanze