Re: [gtkmm] "manage" and Glib::RefPtr

[Christof Petig <christof petig-baender de>]

Daniel Elstner wrote:
> Am Don, 2002-10-10 um 19.01 schrieb Daniel Elstner:
>
> > Am Don, 2002-10-10 um 18.29 schrieb Christof Petig:
> >
> > It's no add-on, GTK+ does it itself all the time.  If we'd do it the way
> > I'm proposing but without enforcing the use of RefPtr<> we wouldn't even
> > loose backward compatibility.  It'd be dangerous (at it is now) and
> > allow bad style though.  (Yes, I really think that using delete in high
> > level C++ code is bad style.)

[I currently use it only for Gtkmm Widgets (and in some places where a 
smartpointer would complicate things) ;-)]

> Sorry, I've to correct myself:  My proposal would include that gtkmm
> methods return RefPtrs to widgets instead of plain pointers, so it can't
> be source compatible.  I think that this would be the only sane thing to
> do -- refcounting isn't something you can decide to use at construction
> time and then forget about it.

Perhaps I should make up a patch so that we do not compare vaporware. 
[I don't know yet when I'm going to find the time, but since one of my 
motivations is to _enable_ the user to use RefPtr _now_, it's high 
priority for me]. Of course unless it's clear that an optional fourth 
memory management scheme is unacceptable to anybody. This would save me 
the time to try it. IIRC implementing refcounting is needed anyway.

Of course I prefer a clean RefPtr solution over any other memory 
management scheme. That's why I sympathize with your position of dumping 
everything else. But I don't think that a widely used library should 
force users to rewrite their code every two years.

I still struggle to port my applications (I maintain about 10-20 gtkmm 
applications) to gtkmm2. Read: I still don't have any of it compiling 
with gtkmm2 [because of CList/CTree dependance].

   Christof