Show quoted text 17 lines
> Thanks Jonas and Leledumbo for your answers. Most of this makes
> sense to me now. Some minor followup questions / comments (snipped)
> C) Just out of curiosity, am wondering why FreeAndNil is global
> procedure instead of a method/destructor of TObject.
...
c:=c.tsomeclass.create;
c.freeandnil
then freeandnil would get, as first (hidden) parameter, the self
pointer. However, this self pointer is a value parameter. So it
would only contain the value of "c", not its address. Hence, there
is no way to set "c" to nil inside the freeandnil method (while
setting the instance variable to nil is the entire reason for using
freeandnil).
--- And one of the features of FreeAndNil is to zero the reference BEFORE deallocating the memory which I assume would be problematic to do "inside" the instance in question.
Show quoted text 10 lines
> 5) Although I can't remember reading it anywhere, I've noticed from
> my own demo programs that the addresses of objects are initially
> set to nil.
That is not correct. All global variables (classes/objects or not)
are initialized to 0/nil, but local variables aren't (except in case
of reference-counted types). Moreover, the contents of a class
instance are also zeroed when creating it.
--- Yes, I was only testing with global object variables. I also noticed that the contents were initially set to zero on creation but the address itself was not set to zero when destroying the object. That bewilderment was cleared up by reading the docs more closely and the answers I got here.
Show quoted text 6 lines
> A) ...
> What is it meant by: "no need to call [create] directly?" How do
> you invoke the constructor without calling it?
I think what is meant, is that if you create a __direct subclass__
of TObject, ...
-- Yes, that makes sense
..there is no need to call TObject's create constructor (e.g., via
"inherited create;") from your own constructors. It doesn't hurt if
you do it of course, and may be good practice to account for future
situations where the parent class may change.
-- As my own debugging aid to check for memory leaks, I've added a global object counter to my own create and destroy routines which keeps track of the net number of instances created/destroyed. Although you probably would not want it in final release code, that might be a situation where TObject.Create might do something.
Show quoted text 7 lines
> ... and ... Why is create not virtual and the destroy destructor is?
Because when creating a class instance, you usually know the exact
class type of that instance ...
...Conversely, many routines that free a class instance, have no
idea about the exact type of that instance ...
-- This is clear to me now.
Show quoted text 10 lines
> B) ...
> What is it meant by: "No other destructor should be implemented?"
It means that you should not add "destructor
my_peculiarly_named_destructor; virtual;" to your own classes. The
reason is that TObject's free method, which is used by pretty much
all code out there, is hardcoded to call "destroy". So if your
destructor is named differently, a lot of existing code will not
properly destroy instances of your class type.
--- Maybe a compiler warning for this situation is warranted?
Show quoted text 5 lines
> ...and... Does it do "something" while the Create constructor
> doesn't?
No, TObject's default destructor does not do anything either.
--- I understand the semantics now. Neither does anything specific but they do "do something"; allocate and deallocate memory as an effect of the root class implementation.
- ROW
