Re: GHashTable and const

["BJörn Lindqvist" <bjourne gmail com>]

Yes, i'm aware of that. Const variables just seem to grow like
mushrooms around const-accepting functions and those inevitably cause
trouble. Inside the function with a const parameter, that parameter
also only has to be passed to const parameter functions. That is
another case where warnings has to be fixed with irritating casts.


2008/7/3, 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*)'
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>


-- 
mvh Björn