Re: freeing GTK+ memory

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

 



-----BEGIN PGP SIGNED MESSAGE-----Hash: SHA1
> With GTK+ you also have the option of inspecting the source code.
this is an advantage over closed-source libraries, I agree, but it isn't optimal. Implementation may change over timeand how guarantees that this won't change in the next release? You cannot always download the source code for the simplequestion "should I free it or not?" when such a fact should stay in the (offline) documentation. Besides you first haveto know how is the general structure of the GTK+/Glib/etc/ libraries. I admit that that is not so difficult to realizebut it takes "a lot" of time if it's your first time.
I agree with Ian that there are some functions that are not properly documented when it comes to the returned memory.
Pablo
- --Pablo Yánez Trujillohttp://klingsor.informatik.uni-freiburg.de/My public key: http://klingsor.informatik.uni-freiburg.de/gpg/supertux.asc

Hrvoje Nikšić wrote:> On Sun, 2008-10-26 at 16:23 -0700, Ian Puleston wrote:>> The documentation for gtk_radio_button_get_group() says that it>> returns a GSList*, but is that a list that it allocated for me so I>> will need to free it, or is it a pointer to an internal GSList that I>> must not free? A call to g_slist_free() didn't break anything> > Note that the fact that g_slist_free() didn't break anything doesn't> prove that the code is correct.  In case of a double free, the breakage> could still occur at an unrelated point later.> gtk_radio_button_get_group() amounts to:> > GSList*> gtk_radio_button_get_group (GtkRadioButton *radio_button)> {>   g_return_val_if_fail (GTK_IS_RADIO_BUTTON (radio_button), NULL);> >   return radio_button->group;> }> > which indicates that you don't get a fresh list.> >> so presumably that's the correct thing to do, but "try it and see">> like that is not really the ideal way to design an app.> > With GTK+ you also have the option of inspecting the source code.> Admittedly not the most pleasant option and in some cases equally> misleading because it leads to confusion between the interface than the> implementation, but in any case more robust than "try it and see".> > _______________________________________________> gtk-list mailing list> gtk-list@xxxxxxxxx> http://mail.gnome.org/mailman/listinfo/gtk-list-----BEGIN PGP SIGNATURE-----Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkkFpXAACgkQDzf8xo+0xRVsfACgun6sDL4NYJJWypXKY1vTDEzlRCMAoIqeKaJz6jvqlzejO4EHxP1briId=lHor-----END PGP SIGNATURE-----_______________________________________________gtk-list mailing listgtk-list@xxxxxxxxxxxxx://mail.gnome.org/mailman/listinfo/gtk-list

[Index of Archives]     [Touch Screen Library]     [GIMP Users]     [Gnome]     [KDE]     [Yosemite News]     [Steve's Art]

  Powered by Linux