Re: GHashTable and const

["Milosz Derezynski" <internalerror gmail com>]

2008/7/4 Alberto Mardegan <mardy users sourceforge net>:

ext Brian J. Tarricone wrote:

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.

Yes, but this is not our case: by introducing const in some of the API parameters we don't restrict their usage: you can always pass them a non-const variable in C++ too, right?

More often than not, in a medium-to-large (let's say non-trivial program) you get data passed from function to function with hard usage of proper const, that is, where you needn't or shouldn't modify data, it's passed to you with const CV. That in turn means you can also only pass it on as const, or use the very fugly (and dangerous) const_cast<> to cast away constness. So while the basic statement is true, in practice it matters a LOT more in C++ in more than just one way. If the API in GLib was changed, i'd expect a good number of C++ apps to fail in compilation due to the change, unforseeably so.

That said, i'm all for the change to add proper CV qualifiers where they should be, reflecting the treatment of data by the functions processing it.
 

------------
Please note that according to the German law on data retention,
information on every electronic information exchange with me is
retained for a period of six months.
[Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]