Re: const fixes seek commit approval

[Havoc Pennington <rhpennin midway uchicago edu>]

On Wed, 28 Oct 1998, Tim Janik wrote:
> 
> if he wants to further operate on that string.
> but requirering an extra variable
>

In every case in Gtk+, there was an extra variable anyway, FWIW...
I didn't have to add any I don't think. I consider Gtk+ a significant
chunk of code...
 
> just for the retrival is actually a hassle, especially for code blocks
> that are somewhat bigger than the above.

If you don't impose the hassle for people who refuse to use const, you do
impose the hassle for people who use const. All your arguments hold
equally in reverse, for this case. For the return value case, they do not
hold in reverse; that's why I can see an exception for that case.

You can say "don't use const then," but it's worth bringing up that in C++
you basically must use const, because static strings are const, and the
standard library makes things const (.c_str() etc) and in general people
use const objects which basically have to return const pointers to any
internal strings. 

Of course, it is good practice to use it in C as well; C++ is not the
whole motivation here. There are unexpected benefits in addition to
catching silly errors: for example, I think when Owen made the inline
image data in gnome-libs const, it saved a whole bunch of memory, because
apps could share the data. 

For Gtk--, we could fix the constness (and we will); but I think there are
good reasons to do it right in straight Gtk+ too, since there are benefits
in C, and C++ people who don't use Gtk--.

> 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**.
> 

So you're saying, if functions don't return const, const should never be
used. If that is the argument, I think functions should return const. If
it's all-or-nothing const should win on general rightness.

Gtk+ is one big hassle for type safety - the whole object system, the cast
macros, the GTK_IS_FOO asserts, the gfoo typedefs. I don't understand why
the hassle is too much hassle in this one specific case; type safety here
buys you as much as it does anywhere else. You could also use comments for
all the other cases: 

/* args are a GtkContainer and GtkWidget */
gtk_container_add(gpointer container, gpointer child);

This avoids the GTK_CONTAINER cast, but it is silly. 

Havoc