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

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].


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]