Re: { Semi-Newbie } Inverse of +initialize?
Re: { Semi-Newbie } Inverse of +initialize?
- Subject: Re: { Semi-Newbie } Inverse of +initialize?
- From: Eric Dahlman <email@hidden>
- Date: Mon, 14 Oct 2002 17:24:49 -0500
Howdy,
On Saturday, October 12, 2002, at 07:21 AM, David Remahl wrote:
That's interesting, and coincidentally exactly what the Objective-C
reference in the current devtools says (p141).
I have been treating -dealloc as an analogue of a C++ destructor,
which
clearly it isn't.
Me too. I think this is a pretty peculiar design detail in the cocoa
runtime.
Actually, using destructors for more than memory management is usually
a bad idea in any language but C++.
Objects doing different kinds of cleanup when destroyed is pretty
common.
An unfortunate source of many brittle designs ;-)
This isn't just about cleanup when the application/process is
terminating,
but also during run. An example is the connection termination.
Thank you for providing the archetypal example of why this is a bad
idea ;-)
The short of it is that almost all objects in Objective-C have
"indeterminate" dynamic extent -- C++ has not such critter. An
object's extent is where it exists in the execution on the program. An
object in C++ which is created on the stack as an automatic variable
has static extent and coincides with the variable's scope. Other
objects created with 'new' have dynamic extent but they will also all
be explicitly destroyed under programmer control so it is not
indeterminate. A parallel to Objective-C's autorelease, a garbage
collector or programmer error ;-) is necessary to create an object of
indeterminate dynamic extent.
The problem with these objects is that there is no way to guarantee
when a given object will be "collected" and therefor we cannot say for
sure if or when the destructor will be called. There can be an
argument made about the "if" being a little to harsh for some
implementations but that point which is guaranteed is not specified and
it may be too late for your needs.
The C++ style of mixing the management of memory in with the management
of other resources simply does not work in this situation. I had to
debug a program once which used object finalization in Java to close
files, it would open them and then assume that they would be closed
when the garbage collector collected them. This worked pretty well
until we optimized the rest of the application and it didn't needlessly
garbage collect any more. Then it would run out of file handles and
crash <GRRRRRR>
The point is that there are two resources being managed, memory and
file handles, and it is not reasonable to assume that they should
coincide. It is just that in C++ you have to spend so much effort on
managing memory it is relatively easy to make a one-to-one mapping from
another resource to some bit of memory and leverage what you already
done.
What is the suggested approach for doing 'destructor' work which isn't
simple deallocation of memory?
I would have to say that you need to manage the resource properly.
There is no free lunch here so you will need to "allocate" and "free"
your resources explicitly and only free memory in your 'destructor'[1].
You did this same work under C++ it was just mixed in with all the
other memory management woes.
Have Fun,
-Eric
----------
[1] I should add that you may want to also include the deallocation
logic in you destructor for the cases which are accidentally missed.
Then when the object is freed you would close the file if it was open
and log an error or warning. Obviously, this makes your program much
more robust.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.