Re: [gtkmm] "manage" and Glib::RefPtr
- From: Christof Petig <christof petig-baender de>
- To: Daniel Elstner <daniel elstner gmx net>
- Cc: Martin Schulze <MHL Schulze t-online de>, gtkmm-list gnome org, ERDI Gergo <cactus cactus rulez org>
- Subject: Re: [gtkmm] "manage" and Glib::RefPtr
- Date: Fri, 11 Oct 2002 09:37:01 +0200
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].
] [Thread Prev