Re: GHashTable and const



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]