Re: [gnome-db] 2 issues with GdaConnection

[Mark Johnson <mrj001 shaw ca>]

Piotr Pokora wrote:
> Mark Johnson writes:
>
> Hi!
>
>   
> > This is something I find difficult in glib/gnome programming in general 
> > - how to know when something needs to be unref'ed, and when something 
> > else might be keeping a reference to your object. 
> >     
>
> Think about g_object_new, g_object_unref as of g_new, g_free.
> The first ones are more complicated of course.
>
>   
> > For example, nothing 
> > in the gda_connection_statement_execute or 
> > gda_connection_statement_execute_select documentation indicates that the 
> > connection reference count will be incremented.  The GdaDataModel page 
> > does not even contain the word connection.
> >     
>
> Point is that when object is created its reference count is increased.
> If you create object, you must unref it. 
This much is quite clear and simple.  It's when functions increment this 
reference count that it gets complex.  As a programmer, I should be able 
to regard the functions in the API as opaque (i.e. I don't need to read 
the source.).

> Code itself might increase
> reference count to avoid ugly problems when some other part of code
> unrefs object in the middle of execution.
> Of course any explicit ref must be followed by unref to avoid memory leaks.
>   
This is the part that gets complex.  When you pass an object to a 
function (other than a function for the aforementioned object), it may 
or may not need to keep a reference to that object.  Without internal 
knowledge of that function, I don't know whether or not it has increased 
the reference count.

Generally, this is poorly documented.  The documentation is unreliable 
in this regard (and I mean all gobject-based documentation, not 
specifically libgda).

I could print the reference count before and after, but this gets ugly 
quickly, and slows development.  The principle of reference counting is 
quite easy to understand.  It's the documentation of whether or not 
something has incremented a reference count where the problem starts.
> g_object_unref also gives you clear API as there's no need to add
> xxx_free or xxx_destroy in API functions.
>   
This is a nice feature of this system.  There's no need to rebuild this 
stuff over and over, and there is that consistent API.
> Piotras
>
>   
Mark