Re: GHashTable and const
- From: "Brian J. Tarricone" <bjt23 cornell edu>
- To: gtk-devel-list gnome org
- Subject: Re: GHashTable and const
- Date: Thu, 03 Jul 2008 13:39:59 -0700
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*)'
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]