Re: const fixes seek commit approval

[Aaron Digulla <digulla wi-pc44 fh-konstanz de>]

Quoting Tim Janik (timj@gtk.org):

> of course not, but that should better be expressed in comments.
> a user is supposed to
>
> gchar *string;
> gtk_label_get (label, &string);
> string = g_strdup (string);
>
> if he wants to further operate on that string.
> but requirering an extra variable
>
> gchar *string;
> const gchar *const_string;
>
> gtk_label_get (label, &const_string);
> string = g_strdup (const_string);
>
> just for the retrival is actually a hassle, especially for code blocks
> that are somewhat bigger than the above.
> there's still the possibility to do the above with the beforementioned
> (gchar**) cast to save the const variable, but that is less then elegant
> and the reasons for avoiding this cast still hold (actually, a good programer
> attempts to reduce casts as much as possible).

:-/ I'm not very comfortable when the user reuses such a variable. The
reason why we want to use const is that the compiler can find more errors
this way (eg. when the user thinks he g_strdup'ed the string and didn't).

So I wouldn't bother that much if the user has to create a second
variable. If that is really a problem, why doesn't gtk_label_get()
simply return the string ? Then the user could write:

    string = g_strdup (gtk_label_get (label));

and everyone would be happy ?

> > Well, this is not the fault of the patch but of GCC. GCC doesn't have
> > meaningful error messages (example: The famous "Parser error before"
> > if you use an unknown type).
> that's certainly right, but already a little besides the point. thing is, if
> gtk doesn't behave truely const enforcing (thus returning const gchar* from
> all functions that don't duplicate a string), it is a pain in the ass if we
> do that for selected functions only, i.e. those that return strings through
> a gchar**.

The more important point IMHO is that you should either use const correctness
everywhere or nowhere. Using it at some places and omitting it at others will
just irritate the developers. So there should be a firm descision if
const correctness is something we want to have and then it should be
enforced:-) Otherwise, we can just leave it as it is and not bother
anymore.

--
Aaron "Optimizer" Digulla             Team AMIGA     AROS Head of Development
Author of XDME, ResTrackLib, CInt.		       <http://www.aros.org/>
"(to) optimize: Make a program faster by improving the algorithms rather than
by buying a faster machine."