#if Edward Diener
> kentda / stud.ntnu.no wrote:
> 
> 
> >I'm afraid I still mostly agree with Al Stevens on the critique of Qt. But
> >I hope we can agree to disagree before I dig myself into a hole and end up
> >sweating over C++ to prove points instead of nice Ruby code that I want to
> >write...  ;-)
> 
> 
> I e-mailed Al Stevens about this issue. I think that if the Qt framework,
> 
> which I don't know, specifies very clearly when ownership occurs, then there
> 
> is nothing conceptually wrong with such a design. I know that in 
> Borland's C++ Builder, which I use extensively for C++ programming, that 
> an ownership scheme occurs which is very easy to understand, and that of 
> course using smart pointers in C++ ( std::auto_ptr<> and Boost smart 
> pointers ) another type of ownership also occurs. As long as the 
> ownership of objects ( or object pointers in C++ ) is easy to understand 
> , I don't see anything objectionable about such a scheme. It did look 
> like, in the case of Qt unfortunately, that the ownership scheme was not 
> easy to understand but was quite abstruse.

Here's all you need to know:

Instances of classes derived from QObject may be given a parent.

If you assign a parent, then that parent takes ownership of your object,
and is henceforth responsible for cleaning up that object.

The parent is usually assigned at creation, by specifying the parent as
a parameter to the constructor, e.g.

new QObject(parentObject);

In real life, this more often looks like the following:

class MyDialog
{
  public:

    MyDialog(QWidget * parent = 0, const char * name = 0)
      : QWidget(parent, name)
    {
      label_ = new QLabel("Hello, world!", this);
    }

  public slots:

    void slotSetLabelText(QString text)
    {
      label_->setText(text);
    }

  private:

    QLabel * label_;
};

Rik