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 <[EMAIL PROTECTED]>: > BJörn Lindqvist wrote: >> On Thu, Jul 3, 2008 at 3:49 PM, Alberto Mardegan >> <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list