Rik Hemsley wrote:

> #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);


That is very similar to C++ Builder, which uses the nomenclature of 
"owner" to denote the component which is the owner, and sounds very 
regular. In Al Stevens' example, however, ownership in Qt occurred 
without the situation which you describe, which is probably one of the 
reasons why he found the idea poor.