Re: Abstract string properties with getter/setter functions
On Fri, 2007-09-28 at 16:24 -0500, Federico Mena Quintero wrote: By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the code that way. Please don't follow that broken pattern. if I may guess, it's because otherwise you'd have to unref the returned widget, which would be a bit odd in the gtk+ context. it also happens in the ::get_filter() method of GtkFileChooser (and GtkRecentChooser), for the same reason: the implementation owns the filter and it's just returning a pointer to it. when you call gtk_tree_view_get_model() you don't unref the returned GtkTreeModel because the tree view widget holds a reference on the model itself, as it happens in this case: [In the file chooser it works because the GtkFileChooser implementation always holds a reference to the preview widget.] yep. it's like returning a private string as a const-gchar*. in these cases work because it has been documented and it's more or less consistent with the rest of the gtk+ API. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On 9/28/07, Federico Mena Quintero [EMAIL PROTECTED] wrote: On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote: Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack done there is somehow possible with objects it is not with strings. GtkWidget * gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser) { GtkWidget *preview_widget; g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL); g_object_get (chooser, preview-widget, preview_widget, NULL); /* Horrid hack; g_object_get() refs returned objects but * that contradicts the memory management conventions * for accessors. */ if (preview_widget) g_object_unref (preview_widget); return preview_widget; } By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the code that way. Please don't follow that broken pattern. [In the file chooser it works because the GtkFileChooser implementation always holds a reference to the preview widget.] I'm pretty sure that it's my code (or, at least, the first usage; it's been cut-and-pasted a couple of times within that file). It's pretty much forced by: - The way GtkFileChooser is set up internally using properties to forward between the different implementations of GtkFileChooser - Widget, Window, and the default implementation - without writing lots of per-property manual chaining code. - The desire to have the public GtkFileChooser wrappers look like most of GTK+ interface where a getter for a constituent widget doesn't ref (think gtk_widget_get_child(), even) And it is pretty safe considering the semantics of the particular situation; if an application sets a preview widget, the file chooser has to hold onto it, and return exactly that preview back out later. But that's only by consideration of the particular situation. It isn't generalizable across all object properties, and definitely not all properties, and even more so not across all getters. It's much easier to write things if you always get a new reference from accessors. It's the only universal pattern. It's not the convenient pattern for using code from C, unfortunately. You see this a lot ... when you take an automatically generated interface (COM, CORBA, etc), and use it from C, you have a lot of tedious dereferencing. But there's no way around that. - Owen [ And yes, I was completely horrified to to see anybody referring to that code as an example to generalize ] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Thu, 2007-09-20 at 08:34 +0200, Raffaele Sandrini wrote: Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack done there is somehow possible with objects it is not with strings. GtkWidget * gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser) { GtkWidget *preview_widget; g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL); g_object_get (chooser, preview-widget, preview_widget, NULL); /* Horrid hack; g_object_get() refs returned objects but * that contradicts the memory management conventions * for accessors. */ if (preview_widget) g_object_unref (preview_widget); return preview_widget; } By the way, this is a *TERRIBLE* idea. I don't remember why I wrote the code that way. Please don't follow that broken pattern. [In the file chooser it works because the GtkFileChooser implementation always holds a reference to the preview widget.] It's much easier to write things if you always get a new reference from accessors. Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, 2007-09-19 at 19:20 +0200, David Nečas (Yeti) wrote: On Wed, Sep 19, 2007 at 06:48:25PM +0200, Raffaele Sandrini wrote: Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. i'm really not sure i understand your problem here... We need a way to steal the string from the property i.e. to make sure its not a copy of the original. The property does not need to be actually backed by a string. It just has to accept a string in the setter and produce a string -- a new string -- in the getter. For instance GtkCellRendererText has properties background wich is a string (write-only though) and background-gdk which is a GdkColor. They are views of same thing and what is this actual internal representation is none of your business. To sum it up, you cannot steal something that is owned by you from the begining. Properties generating things are a complete different story. We have to treat them separately. Properties transferring ownership will need to be specially marked in Vala. Raffaele ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote: BTW: There are equal issues with properties returning objects only there you can add a hack into the getter unrefing the object before returning it. This is not applicable with strings. this is not applicable with objects. as soon as you called unref(obj), the object will be destructed and gone, you can't hand it on any further, obj will point to freed memory. in some rare cases and if you're lucky, the object might stay around a little longer because someone else could coincidentally hold another reference. but this can't be relied upon. a well formed getter implementation might do: return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL)); once you g_object_unref() this return value, it'll be instantly vaporized with a crushing noise (if you hooked up pulseaudio via destruction emission hooks ;) You can check the ref count first. erm, no. that's at least not a clean solution, ref counts may increase and decrease at any point in time for random reasons (caches, garbage collection algorithms, etc...), even from concurrently running threads without holding the GDK lock. Take a look at the GtkFileChooser interface there this hack is used several times. (and annotated as such) hm, not here: $ fgrep ref_count gtk/gtkfilechooser*.c $ Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack done there is somehow possible with objects it is not with strings. GtkWidget * gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser) { GtkWidget *preview_widget; g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL); g_object_get (chooser, preview-widget, preview_widget, NULL); /* Horrid hack; g_object_get() refs returned objects but * that contradicts the memory management conventions * for accessors. */ if (preview_widget) g_object_unref (preview_widget); return preview_widget; } All we need from you is either a solution or the statement that this is not possible with gobject properties ;). i don't quite get what you're trying to achive. but if efficiency is your only concern, i do think that you can spare a string copy by using g_object_get_property() instead of g_object_get(). it just still will be internally copied when it's passed around as a GValue (g_object_get just does two copies alltogether, the second of which needs to be freed by tha caller). That might be true but does not help here. We use getters/setters all through Vala for several reasons including the ability to embed a getter/setter in any kind of C expression and due to speed concerns with GValue. The memory convention of getters/setters is to return weak references. Therefore we think, using virtual setter/getter for virtual/abstract properties would be a solution, but I'd hoped you have a more simple one ;). cheers, Raffaele ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Thu, 20 Sep 2007, Raffaele Sandrini wrote: On Wed, 2007-09-19 at 19:17 +0200, Tim Janik wrote: erm, no. that's at least not a clean solution, ref counts may increase and decrease at any point in time for random reasons (caches, garbage collection algorithms, etc...), even from concurrently running threads without holding the GDK lock. Take a look at the GtkFileChooser interface there this hack is used several times. (and annotated as such) hm, not here: $ fgrep ref_count gtk/gtkfilechooser*.c $ Take a look at 'gtk_file_chooser_get_preview_widget'. While the hack done there is somehow possible with objects it is not with strings. GtkWidget * gtk_file_chooser_get_preview_widget (GtkFileChooser *chooser) { GtkWidget *preview_widget; g_return_val_if_fail (GTK_IS_FILE_CHOOSER (chooser), NULL); g_object_get (chooser, preview-widget, preview_widget, NULL); /* Horrid hack; g_object_get() refs returned objects but * that contradicts the memory management conventions * for accessors. */ if (preview_widget) g_object_unref (preview_widget); this code is not peeking at preview_widget-ref_count, it just always unrefs because by getting it always owns a returned reference. return preview_widget; } All we need from you is either a solution or the statement that this is not possible with gobject properties ;). i don't quite get what you're trying to achive. but if efficiency is your only concern, i do think that you can spare a string copy by using g_object_get_property() instead of g_object_get(). it just still will be internally copied when it's passed around as a GValue (g_object_get just does two copies alltogether, the second of which needs to be freed by tha caller). That might be true but does not help here. well, you still fail to say *why* this does not help or poses a problem for you. We use getters/setters all through Vala for several reasons including the ability to embed a getter/setter in any kind of C expression and due to speed concerns with GValue. The memory convention of getters/setters is to return weak references. this is *not* a convention of getters in glib/gtk programs. like i said in my first email, some getters return peeked contents, some return duped/referenced contents. technically, it is *not* possible to implement all getters as peeking functions because return values may be constructed on the fly. so any convention that demanded only peeking getters would be in error because it'd be technically impossible to implement thoroughly. (maybe what you're saying is that this is a convention for vala getters... but then, that's something you'd very badly have to fix, because it is *not* implementable for all C programs, even beyond glib/gtk programs.) cheers, Raffaele --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Abstract string properties with getter/setter functions
Hi there, While implementing abstract properties in Vala we encountered a problem regarding string properties with getter and setter functions: public interface Test.MyIface { public abstract string text { get; } } A getter function of an abstract string property looks like: char* test_my_iface_get_text (TestMyIface* self) { char* value; g_object_get (G_OBJECT (self), text, value, NULL); return value; } Property accessors in Vala always return weak references. This leads to a memory leak in the calling function of the getter. We want property accessors to return weak references so just redefine the accessors to return a strong reference is only a last-resort-option. Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. BTW: There are equal issues with properties returning objects only there you can add a hack into the getter unrefing the object before returning it. This is not applicable with strings. cheers, Raffaele ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On 9/19/07, Raffaele Sandrini [EMAIL PROTECTED] wrote: Ok i see there is need to clarify things. On Wed, 2007-09-19 at 17:53 +0200, Tim Janik wrote: On Wed, 19 Sep 2007, Raffaele Sandrini wrote: Hi there, While implementing abstract properties in Vala we encountered a problem regarding string properties with getter and setter functions: public interface Test.MyIface { public abstract string text { get; } } A getter function of an abstract string property looks like: char* test_my_iface_get_text (TestMyIface* self) { char* value; g_object_get (G_OBJECT (self), text, value, NULL); return value; } Property accessors in Vala always return weak references. This leads to a memory leak in the calling function of the getter. i'm not sure what you mean with weak/strong references when it comes to strings. in C, pointers can be handed out which point to 0-terminated char arrays that represent strings. there's on reference counting for strings in C as there is in C++. per convention, for glib/gtk programs, some such string pointers must be g_free()-ed once. With strong/weak references is talk about ownership. If some code needs ownership over a string it will dup the string. callers of getters have to free the returned string in C. for glib/gtk programs, if the caller doesn't need to free the string, the return value should be G_CONST_RETURN gchar*. That's right since the getters do not claim ownership they do not need to free the strings. The problem is the caller assumes a weak reference and will dup it if it needs ownership. The point here is that we are talking about *abstract* properties i.e. i do not know whether the implementation uses a static string or not. I have to call g_object_get whether i want to or not. We want property accessors to return weak references so just redefine the accessors to return a strong reference is only a last-resort-option. requesting that all string return types should be const char* is technically not possible, because some strings need to be constructed in getters. people who don't want to deal with these memory allocation issues (const strings vs. caller-needs-to-free strings) should stay away from C, maybe even C++, and use python, java, scheme, other-garbage-collected languages. Vala needs to deal with this issues to enable users who do not want to deal with it an easy life. Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. i'm really not sure i understand your problem here... We need a way to steal the string from the property i.e. to make sure its not a copy of the original. It's difficult to imagine how one would enforce this, given that the implementation has complete freedom to copy the string. The GOB string getters always returned an allocated string. I'm afraid you may have to resort to that in general. BTW: There are equal issues with properties returning objects only there you can add a hack into the getter unrefing the object before returning it. This is not applicable with strings. this is not applicable with objects. as soon as you called unref(obj), the object will be destructed and gone, you can't hand it on any further, obj will point to freed memory. in some rare cases and if you're lucky, the object might stay around a little longer because someone else could coincidentally hold another reference. but this can't be relied upon. a well formed getter implementation might do: return g_object_ref_sink (g_object_new (MY_TYPE_DATA_OBJECT, NULL)); once you g_object_unref() this return value, it'll be instantly vaporized with a crushing noise (if you hooked up pulseaudio via destruction emission hooks ;) You can check the ref count first. Take a look at the GtkFileChooser interface there this hack is used several times. (and annotated as such) All we need from you is either a solution or the statement that this is not possible with gobject properties ;). Forgot to post the bug against Vala: http://bugzilla.gnome.org/show_bug.cgi?id=472904 Hope things are more clear now. cheers, Raffaele ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Abstract string properties with getter/setter functions
On Wed, Sep 19, 2007 at 06:48:25PM +0200, Raffaele Sandrini wrote: Since we do not see a way around this (yet) and we could not find an example with strings in another project. I'm asking here if there is a nice way around this. i'm really not sure i understand your problem here... We need a way to steal the string from the property i.e. to make sure its not a copy of the original. The property does not need to be actually backed by a string. It just has to accept a string in the setter and produce a string -- a new string -- in the getter. For instance GtkCellRendererText has properties background wich is a string (write-only though) and background-gdk which is a GdkColor. They are views of same thing and what is this actual internal representation is none of your business. To sum it up, you cannot steal something that is owned by you from the begining. Yeti -- http://gwyddion.net/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list