Delphi classes (Was: bugs, incompatibity, function attributes)_(re)

Thu, 3 Jul 1997 07:29:12 -0700 (PDT)

On Thu, 3 Jul 1997, Frank Heckenbach wrote:

> The African Chief wrote:
> 
> I think the latter would be a more consistent interpretation (at least for
> us, even if Delphi does it otherwise). So "class" = "pointer to object",
> approximately...
> 
> > 	e.g.,  "Var Foo : MyFoo"
> > 	=       "Var Foo : ^MyFoo" in the current OOP model

Delphi does do it otherwise as in this example

type

   TMyObject = Class(TObject)
    .
    .

var
  VarMyObject : TMyObject;

> Saves declaring those "PFoo" types, OTOH makes it impossible to declare
> global or local objects variables (without the overhead of allocating
> memory). If we have objects and classes, the programmer can choose what
> (s)he prefers.

Delphi does not allocate memory for object variables untill the object is
actually created with its create method.
> 
> >    [b] the constructor does the heap allocation stuff,
> > 	e.g., "Foo := MyFoo.Create"
> > 		*allocates memory for Foo "(New, Foo)"
> > 		*calls Foo^.Create (constructor)
> 
> So it's the same as "Foo := New(MyFoo, Create)" in BP? Why not!
> Shorter to type, perhaps easier to read (once one gets used to not looking
> for "New").

This is also how Delphi works, again;

   VarMyObject := TMyObject.Create;

> What about destructors? Does Delphi still use "Dispose", or has it another
> syntax too, or does it dispose of objects automatically. (C++, BTW, does the
> latter. It destroys e.g. local objects at the end of the function
> automatically. This is possible because in C++ every class has exactly one
> destructor. I guess they set the pointer to nil automatically at the
> beginning (and set it back to nil if the destructor is called manually),
> so they can easily find all local objects that "exist" and destroy them.)

Delphi has two methods for object destruction, Free and Destroy.  However,
Free is what should always be used.  It deallocates memory etc. and calls
destroy only if the object is not nil.  This provides a safer, cleaner
destruction of the object.

> > 6. All classes to have the same ultimate ancestor object.
> 
> The same discussion as with objects recently... ;-)
> Is this really necessary (if so, for what?), or is it sufficient if all
> classes in a given library use the same ancestor by convention?

In Delphi, the common object ancestor (TObject) provides the most basic
methods and properties that ALL objects need (creation, destruction,
etc.).  These are the methods/properties that are unlikely to be
overridden (its rare that you would need a different destructor for
example) and having a common ancestor provides the programmer with a ready
to go foundation for his/her objects.  I think a common ancestor is the
right way to go.

Larry Carter
lcarter@powerslave.jf.intel.com

Larry Carter (lcarter@powerslave.jf.intel.com)