Using uic generated classes as a base class in public API

Matt Rogers mattr at
Wed Mar 2 23:13:02 UTC 2005

On Wednesday 02 March 2005 02:56 pm, Richard Dale wrote:
> On Wednesday 02 March 2005 17:32, Matt Rogers wrote:
> > Hi,
> >
> > It's a huge mistake to use classes generated by uic in public API. The
> > reason for this is that uic generated classes lack virtual destructors.
> > Without virtual destructors, derived class destructors are never called,
> > and then leak memory, objects don't get deleted properly, in essence,
> > you're screwed.
> Typically subclasses of a uic base class don't use any resources that need
> to be freed in the destructor. Can you show an example of some code which
> does leak memory?
> > Since, AFAIK, the kdevelop project as a whole doesn't care about BC, we
> > need to fix the classes that use a uic generated class as a base class. I
> > first noticed the problem in languages/lib/designer_integration but i
> > imagine it's elsewhere too.
> >
> > Here's how we fix it:
> >
> > - Change the classes that have a uic generated class as a base class to
> > store a pointer to the uic generated class instead.
> > - Make the base class derive from the appropriate widget.
> > - Convert any uic generated class that's not a QWidget (i.e. QDialog or
> > similar, to QWidget) to a QWidget
> >
> > I'll leave languages/lib/designer_integration to adymo, but will try to
> > go through kdevelop and change the other relevant classes throughout the
> > week.
> This seems to be a major change to solve a problem which I don't believe
> exists. Have you measured any memory leaks?

There probably isn't a problem currently, since the only classes I've looked 
at has been the Qt Designer Integration classes, and the only pointer there 
that would require a delete and ergo, the use of the destructor,  has a 
QObject parent, so it'll be deleted when its parent is.

However, this something to keep in mind for later, since I don't think that 
it's a good idea to derive from uic generated classes in public API in the 
first place...


More information about the KDevelop-devel mailing list