Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


Is it ok to have a class with no parent?

Posted on 1998-09-16
Medium Priority
Last Modified: 2013-11-23
I am trying to track down some memory leaks in my project using Memory Sleuth. I am wondering if there is a problem declaring (formless) classes having no parent, thereby not calling an inherited Create and Destroy in the constructor and destructor respectively?
Question by:tomcorcoran
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions

Expert Comment

ID: 1339960
First of all, when you make an object that doesn't inherit from anyone, Delphi automatically makes Tobject it's ancestor. So you can ALWAYS call inherited destroy (Actually calling Free is recommended, because it checks for nil pointers before destroying).  So that will solve your problem. But I don't think the memory leaks comes from that!

Author Comment

ID: 1339961

Thanks for the answer.

" So you can  ALWAYS call inherited destroy (Actually calling Free is recommended, because it checks for nil pointers before destroying)."

I always call Free, however what you are saying doesn't make much sense, I was asking about "inherited Destroy" the  last line normally in a destructor, you wouldn't use Free in this case. You say I can always call it, I am trying to find out is it cool not to in this instance (similiarly with inheritd create)..

Any other feedback anyone?

Thanks, Tom.

Expert Comment

ID: 1339962
You can do that for decendent of TComponent only but not TClass in general. This is because all component has an owner, and the owner is reponsible to free the owned component before the owner itself is destroyed.
p/s: I hope I understand your question correctly: when you say parent you mean owner?

Concerto's Cloud Advisory Services

Want to avoid the missteps to gaining all the benefits of the cloud? Learn more about the different assessment options from our Cloud Advisory team.


Expert Comment

ID: 1339963
You only have to explicitly call the destructor (or free or whatever) of the base class if it allocated memory. TObject does not do this., it only implements methods and you thus cannot leak by not calling it's destructor.

Where do you expect your leak is ? What do you do in your class ?
It is generally bad programming practice to use something like new or malloc in constructors because it can cause problems. If you do not do this the classes should destroy ok unless you are dropping pointers or not calling inherited destructors.

A common error is not declaring a virtual destructor in your class or actually the class of which type you are freeing. If you e.g. derive TMyObject from TObject and then access TMyObject via a pointer of type TObject simply freeing the TObject will result in a leak since the compiler and the app will not know that it is actually a TMyObject that has to be freed ! If you do have virtual functions that cause VTable entries to be made the code will determine the type from the VTable and it should free correctly. It is however a good Idea to always free something cast to the same type as it was created.

I do not know what you did in your code so forgive if this is completely off track ...

Hope that helped !

Expert Comment

ID: 1339964
Hi tomcorcoran,
I don't know what's inside your classes, but if use descendent of TComponent instead of TObject (implicit also if don't declare anything) the memory management is always correct.
Delphi Help -> "Calling Free for a component, will call Free for all components that it owns, that is, all components in its component list."
So it shouldn't be so difficult to change yoru classes declaration inheriting from TComponent.
You just need to add AOwner in your create method.
e.g. declaring two kind of classes like follow :

TMyContained = class(TComponent)
   name : string;
   list : TStringList;
   procedure DoSomethingInside;
   . . .
   constructor Create(AOwner : TComponent);
   destructor destroy; override;

TMyContainer = class(TComponent)
    MyContained : TMyContained;
   constructor Create(AOwner : TComponent);


// TMyContainer
constructor TMyContainer.Create(AOwner : TComponent);
    inherited create(AOwner);
    MyContained := TMyContained.create(self);

// TMyContained
constructor TMyContained.Create(AOwner : TComponent);
    inherited create(AOwner);
    list := TStringList.create;

destructor TMyContained.free;
    // if you have objects in the list you must make a loop to free any of them
   //  before freeing the list
    inherited destroy;

This way you'll discard any allocated memory. Note that because of TStringList doesn' descend from TComponent you need to free it by code.
So if you want to declare something directly descending from TObject you must manage by yourself free and destroy methods.
Sometimes, like using TStringList, it's necessary.
I hope tehere's something helpful for you .

Author Comment

ID: 1339965
Giovanni, thanks for the reply, I have many classes liker this, this is not what I am asking however, JimBob pretty much answered it, saying it's cool not to call the inherited create and destroy when TObject is the parent (explictly or implicitly). JimBob, let's put this one down, most a dummy answer and I'll grade. Tom.

Expert Comment

ID: 1339966
Hi Tom,
you wrote about 'Memory Sleuth', is it a good tool for memory management ?
I've been on FILEZ looking for it but I couldn't find anything.
I'm looking for a good tool so please tell me more about it.


Author Comment

ID: 1339967
Hey, check out UNDU - http://www.undu.com/Articles/980807c.html, I find Memory Sleuth the best. Tom

Accepted Solution

JimBob091197 earned 200 total points
ID: 1339968
Hi Tom

I had actually commented in your other question, so only found your comment here by coincidence!  :-)

Anyway, if you're happy with my comment on the other question and are still happy for it as an answer, then here it is.


Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

A lot of questions regard threads in Delphi.   One of the more specific questions is how to show progress of the thread.   Updating a progressbar from inside a thread is a mistake. A solution to this would be to send a synchronized message to the…
In my programming career I have only very rarely run into situations where operator overloading would be of any use in my work.  Normally those situations involved math with either overly large numbers (hundreds of thousands of digits or accuracy re…
In this video, Percona Solution Engineer Dimitri Vanoverbeke discusses why you want to use at least three nodes in a database cluster. To discuss how Percona Consulting can help with your design and architecture needs for your database and infras…
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB. To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…
Suggested Courses

609 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question