Re: Fwd: Re: GTK_FLOATING broken in 2.9?
- From: Yevgen Muntyan <muntyan tamu edu>
- To: gtk-devel-list gnome org
- Subject: Re: Fwd: Re: GTK_FLOATING broken in 2.9?
- Date: Thu, 15 Dec 2005 00:33:52 -0600
ANDREW PAPROCKI, BLOOMBERG/ 731 LEXIN wrote:
When you are calling your own code, it is not that
much to keep track of, but when I write code that is used by 1000 developers it
is much easier for me to take care of the reference issues inside the API and
make the large group of unknown developers free from unknowingly creating
reference counting bugs.
So, the thousands of another developers now will have to check
documentation for any GObject-derived class to figure out whether
they own reference or not. This is exactly why it's good when you
invent your wrappers, where it's clear that wrapper is made for
purpose and one might be interested in what that wrapper does.
So, if before the usage pattern was:
object = create_object ();
...
g_object_unref (object); /* I do know I own it */
now it will be
object = create_object ();
g_object_ref_sink (object); /* who knows what will happen in ... */
...
g_object_unref (object);
Is it really good for glib, the library which is used by all people
using glib,
not just those 1000 unknown developers who are not aware of the need
to free allocated memory?
These arguments about bugs and stuff are good arguments about why
one should use C++ or whatever other language with some sort of automatic
memory management. C is known not to be safe, and it's known that you
must be careful. After introducing floating references one will still need
to be as careful, but he also will need to check one more thing - floating
reference (or sink it as soon as possible).
Maybe real solution would be for those 1000 guys to use mono or something?
In short, it's nice that glib will be more safe for those who do not check
what his code does, but if one tries to write safe code, he'll get one more
headache.
Regards,
Yevgen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]