Re: Behaviour of getters wrt dup/ref

[Behdad Esfahbod <behdad behdad org>]

On Sun, 2007-09-16 at 03:03 -0400, David Nečas (Yeti) wrote:
> On Sat, Sep 15, 2007 at 11:08:38PM -0400, Behdad Esfahbod wrote:
> > On Fri, 2007-09-14 at 10:35 -0400, Alexander Larsson wrote:
> > > 
> > > char *      g_data_input_stream_get_line (GDataInputStream *data_stream,
> > >                                           gsize             *length,
> > >                                           GCancellable     *cancellable,
> > >                                           GError           **error);
> > > 
> > > This actually reads new data from the stream, so it has to dup. One
> > > could imagine a similar call that returns some form of object instead
> > > of a string. 
> > 
> > I think it's pretty common in glib and pango at least to return
> > g_strdup'ed strings.  The no-ref-count rule is mostly for objects that
> > have a literal ref/unref pair.
> > 
> > Other than that, for functions that return read data from the stream,
> > some people may have reasons to want to avoid malloc/free'ing on each
> > line.  One way to work around that is to have the function take a
> > GString, so you can reuse the buffer from the previous line.  I know
> > most people are not a big fan of that idea though.
> 
> The right interface for this type of functions have been
> already invented: that of glibc's getline.  It can allocate
> new buffers, it can reuse existing buffers resizing them if
> necessary -- and it can be even used with GStrings [if they
> use the same memory allocator] although that's a bit dirty.

Well, that's exactly what happens if you make the API take GString.

> Yeti

-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759