Re: Compiler error with g_string{_append}_printf

[David <dbree duo-county com>]

On Fri, Dec 17, 2004 at 01:48:03PM -0500, Owen Taylor wrote:
> On Fri, 2004-12-17 at 10:31 -0600, David wrote:
> > On Fri, Dec 17, 2004 at 01:36:17AM -0800, Brian J. Tarricone wrote:
> > > David wrote:
> > >
> > > > I've come across something that has me baffled - it may be obvious, but
> > > > I've fooled with this and can't see what's wrong..
> >
> > > [snip]
> > >
> > > >   msg = g_string_append_printf (msg, "  -- G09Dis V %s --\n\n%s\n%s", 
> > > >   "2.0",
> > > >                      "  A graphical front-end to \"os9disasm\"\n",
> > > >                      "  This version is strictly BETA!!!");
> >
> >
> > > there's the problem.  g_string_append_printf() doesn't return anything.  
> > > it takes a GString as the first argument, and appends your 
> > > format+arguments to it.  that's it.  the "msg =" is unnecessary, and 
> > > that's what's causing the error.
> >
> > Oh WOW!  I knew it had to be something simple..  I didn't study the API
> > close enough I guess, but I realized that the non-printf functions _did_
> > return the GString * and simply extended this to the printf-variety.. But
> > now I'm wondering ..
> >
> > Why would g_string_append need to return the GString pointer and
> > g_string_append_printf not?  You're modifying the string in both cases.
> > I now notice that none of the *printf* functions return a value while
> > the non-printf functions do.
> >
> > Actually, I can't see why the GString would ever have to change anyway.
> > It's a structure which contains a pointer to the actual string as one of
> > its elements.. From my perspective, there's no need for the GString
> > structure to ever move, but just change the values in its elements.
> >
> > The return of the GString * could be a convenience for the programmer,
> > where you could nest your functions, ..like g_printf(
> > g_string_append(...)), but if this is the only reason, it would be just
> > as useful with the printfs, too.
> >
> > Now that I see this difference, it's not a problem, but from my
> > superficial overview, it seems to be a (slight) inconsistency.
>
> The return is *always* the string passed in. This is to allow writing
> something like:

Well.. actually, in the case of GString, it's not a pointer to the
string itself, but a pointer to a structure that contains a pointer to
the string.  I'd think that this should never have to change.

> char *
> concat_strings (const char *a, const char *b)
> {
>   return g_string_free (g_string_append (g_string_new (a), b),
>                         FALSE);
> }

Exactly.  I mentioned this above.

> Upon further consideration, encouraging people to do such things
> was revealed to be a bad idea, so more recently added functions
> in GString may not have the return value.

This is apparently the case.  Although the above technique is sort of
convenient, it can make the code less readable.  Also, I saw a rather
lengthy thread either here or elsewhere recently where it was declared
that some compilers don't handle precedences the way we're used to
thinking, and can lead to problems.  Lately I've begun to break up some
of the things I'd been nesting.

As for GString, it seems that I saw in a tutorial somewhere that they
claimed that a GString append might change the address of GString (but
I'm now beginning to doubt that - or I may be confusing this with the
g_str functions).  The biggest problem I see in the way the different
GString functions return values is that when you do like I did, become
familiar with the fact that g_string_append(), for example, returns a
pointer (and _thought_ I was advised to update the pointer), and naively
assumed that g_string_printf() would do likewise, does lead to
confusion.

Thanks for the reply.  I am learning more and more about GTK all the
time.