[wx-dev] Re: wxDataViewCtrl issues

[Vadim Zeitlin]

On Sun, 04 Feb 2007 23:27:16 +0100 Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:

FM> So, if even you don't agree that these methods are missing, can we add them?

 Unless anyone objects or at least proposes a way to do what we want
without them, I think we should.

 And we also must make its dtor private as it should never be deleted
directly (only as a result of DecRef() call).

FM> All refcounted object APIs I know have them; e.g.
FM> 
FM> http://developer.gnome.org/doc/API/2.0/gobject/gobject-The-Base-Object-Type.html#g-object-ref

 And so does wxGridCellWorker (i.e. even classes elsewhere in wx have them
too).

FM> > FM> bool wxDataViewCtrlBase::AssociateModel( wxDataViewListModel *model )
FM> > FM> {
FM> > FM>      /* current code:    m_model = model;   */
FM> > FM> 
FM> > FM>      .... // gap #3
FM> > 
FM> > 	if ( m_model )
FM> > 		m_model->DecRef();
FM> > 	m_model = model;
FM> ok so far
FM> 
FM> 
FM> > 	// no IncRef() call as we take ownership of it here
FM> hmmm this is not very clear to me... if the wxDataViewCtrl takes the ownership
FM> (instead of just adding its own reference) of the wxDataViewListModel, it makes
FM> it impossible to reuse that same wxDataViewListModel into another
FM> wxDataViewCtrl, isn't it?

 I thought that we wanted the default behaviour to be for the control to
take ownership of the model because I believed this was how the current
code worked. But it seems I was wrong and that it does not take its
ownership now. In this case it should probably indeed increase the
reference count but, as you noticed, not taking ownership of the passed in
pointer makes it very easy to leak memory. This could be mitigated by using
a smart pointer for model objects (which would call DecRef() implicitly in
its dtor).

 Regards,
VZ