Re: [Re: [gtkmm] technical question: GTKMM_LIFECYCLE]
- From: Murray Cumming <murrayc usa net>
- To: Christian Meyer <chrisime gnome org>, Martin Schulze <MHL Schulze t-online de>
- Cc: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [Re: [gtkmm] technical question: GTKMM_LIFECYCLE]
- Date: Fri, 27 Sep 2002 19:16:38 +0100
Christian Meyer <chrisime gnome org> wrote:
> Am Fre, 2002-09-27 um 13.36 schrieb Martin Schulze:
>
> > - gtkmm objects that were not manage()ed are reference counted non
> > the less. However, when the reference counter reaches zero the
> > c object is deleted but the c++ instance is not (only gobject_ is
> > set to 0). I understand that this is necessary to allow for gtk
> > objects on the stack. But is this behaviour compatible with smart
> > pointers? In other words: shouldn't the c++ instance be deleted
> > when the reference counter reaches zero and the object has been
> > allocated on the heap?
>
> well, that's also what I noticed. The _destroy_c_instance() method is on
> crack (or maybe murray was ;-) )
Christian, you are making as much sense as ever. I suggest you try to be more
constructive.
> Thing can be cetainly done more consistently. I had a closer look at it
> last weekend and what I found out that it's far too compicated and there
> are still many TODO's in the code.
> Maybe we can work together on a better solution!
Christian, this is just you shooting your mouth off about something you don't
understand, and telling us that you are going to do some work that you will
never do.
> > Anyway, sigc++ seems to propose yet a different behaviour (second
> > scenario):
>
> I don't know SigC, but let me comment on it...
[snip]
> OK, that's what I also dislike about gtkmm. Seems like in SigC the
> design is much cleaner!
[snip]
> I only get that half-way.
So basically, you understand nothing, but you're happy to attack us in strong
terms. I'd forgive it of somebody new, but I know that it's all you ever do.
Please take this personally.
Murray Cumming
murrayc usa net
www.murrayc.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]