Re: [gtk-list] Re: Gtk-- refcounting question



Hi, Owen

the points, that I was trying to make, was the following:

1. If I create a Gtk_Object (C++, that is), it should live exactly until
I destroy it. That breaks down into: It will not be deleted, even if the
C-Part is def-refcounted to 0 (e.g. I might want to reparent)(so that
means refcount up by 1 in the C++-constructor). And it should disappaer,
when I destroy it. If I got it right, you're saying, that the C++-Part
can not tell gtk to destroy the object, because gtk might still have
some references to it?? In that case it should at least be destroyed (in
the sense you said -- unmapped) and C++ should be unable to reference it
any more. 

I am rather unsure, if you can simply use the C-refcounting in C++ to
achieve something like "smart pointers", because a C++-programmer would
again expect a window, he has two smart-pointers to, to be destroyed, if
he destroys both. So C++ would IMHO have to do a second layer of
ref-counting.

I also dont't think, that ref-counting should be visible in C++ at all.
C++ is (through the automatic destructor call on deletion) able to
handle this in a far more elegant way (using smart-pointer), just like
your CORBA-example. I suspect, thats why it is called _duplicate, not
ref, because the "unref" is (I suspect, not know, so correct me ;-) done
automatically by the destructor.

BTW: here is a nice page on smart-pointers.
http://web.ftech.net/~honeyg/articles/smartp.htm

Bye,
Sebastian
-- 
+--------------============##################============--------------+
| Sebastian Wilhelmi, Institut fuer Rechnerentwurf und Fehlertoleranz, |
| Universitaet Karlsruhe;  Gebaeude 20.20, Raum 263, D-76128 Karlsruhe |
| mail: wilhelmi@ira.uka.de; fax: +49 721 370455; fon: +49 721 6084353 |
+----------------> http://goethe.ira.uka.de/~wilhelmi <----------------+



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