Re: GHashTable and const

["Brian J. Tarricone" <bjt23 cornell edu>]

BJörn Lindqvist wrote:
> On Thu, Jul 3, 2008 at 3:49 PM, Alberto Mardegan
> <mardy users sourceforge net> wrote:
> > ext Havoc Pennington wrote:
> > > Whether you agree or not, the GLib types don't use const in their API,
> > > so if you try to use const yourself on these types you're just signing
> > > up for pain. It won't work well or do anything useful. (If _all_ the
> > > methods on an object are non-const, all the const keyword does is make
> > > you do a bunch of casts.)
> > While I tend to agree that const in C is of limited use, I find it a nice
> > way to tell the users of an API not to modify/free certain data.
> > So, when I am the owner of a GHashTable and I'd like to have others access
> > it in read-only mode, I'd use a const modifier on it.
> >
> > On your past mail, you write that const is not useful in C, but on the other
> > hand you don't write that it's harmful either.
>
> It is line-noise. It contributes nothing to the clarity of the code,
> because it is already obvious enough that g_hash_table_size and
> similar functions doesn't modify the hash table. It makes the API more
> annoying to use as you'll get more "discards qualifiers from pointer
> target type" unless you add non-const casts when you use const
> variables. If you compile some GNOME projects you'll find that that
> warning is one of the most common ones.

I'd doubt this would be an issue.  You're talking about the reverse 
problem.  If 'const' qualifiers were added to current glib API 
functions, there would be no new warnings.  passing a non-const pointer 
to a function that accepts a const pointer does not generate a warning. 
 The reverse (passing a const pointer as a non-const function 
parameter) does cause a warning, but that wouldn't be the problem caused 
by adding const to some glib functions.

Now, that's for C.  For C++ passing a const pointer to a function 
expecting a non-const pointer actually a hard *error*[1].  So the API 
couldn't be changed in this way without likely breaking any C++ 
application that uses these glib data structures.

> It is just a lot of work and annoyance for a (until someone profiles
> the API with and without const modifiers) totally imaginary speed
> benefit.
>
> > To put some more meat into the discussion, I point out that GValue's APIs
> > make heavy use of the const modifier, and from the user point of view that's
> > very helpful.
>
> In what way?

Personally, I mainly see it as a hint to the programmer so I can tell at 
a glance that the function doesn't modify the parameter (const) or may 
modify the parameter (non-const).  I'd agree that any speed benefits are 
probably very small (if nonexistent), so the burden would be on someone 
to benchmark to prove otherwise.  If the API were being designed from 
scratch, I'd say sure, use const as a semantic identifier.  But at this 
point it's just too late to do it without breaking C++ programs that use 
glib.

	-brian

[1]
$ cat foo.cpp
static void foo(char *bar) { }

int main(int argc, char **argv)
{
    const char *moo = 0;
    foo(moo);
    return 0;
}
$ g++ -c foo.cpp
foo.cpp: In function 'int main(int, char**)':
foo.cpp:6: error: invalid conversion from 'const char*' to 'char*'
foo.cpp:6: error:   initializing argument 1 of 'void foo(char*)'