changing from
g_hash_table_size (GHashTable *hash_table);
to
g_hash_table_size (const GHashTable *hash_table);
would to break any C++ code? It would to make some bunch of
const_cast unneeded and noop -- yes. But break... hard to imagine.
Anything assigning or passing in g_hash_table_size
On Mon, 2008-07-14 at 23:52 +0300, Felipe Contreras wrote:
I don't get it, can you explain how exactly?
The function prototypes will be different, so you won't be able to
assign without casting, or else changing the type of thing holding the
function pointer.
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
2008/7/4 Alberto Mardegan [EMAIL PROTECTED]:
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
On Thu, Jul 3, 2008 at 2:34 PM, Ross Burton [EMAIL PROTECTED] wrote:
On Thu, 2008-07-03 at 14:21 +0300, Andrew W. Nosenko wrote:
On Thu, Jul 3, 2008 at 2:11 PM, Rui Tiago Cação Matos
[EMAIL PROTECTED] wrote:
On 03/07/2008, Alberto Mardegan [EMAIL PROTECTED] wrote:
Hi, quick question: why do
Because const in C is crippled, unlike in C++ where its actually useful.
Soory, but you aren't right:
Yes, he is, but you did not understand him. He was making a language
comment, not an implementation comment.
const in C does not propagate as usefully as you would like. Therefore,
the
Hi,
This is in the archives a bunch of times, for example the first google
hit I got was
http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
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
ext Havoc Pennington wrote:
Hi,
This is in the archives a bunch of times, for example the first google
hit I got was
http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
Ah, sorry, I only researched about GHashTable.
Whether you agree or not, the GLib types don't use const
Morten Welinder wrote:
const in C does not propagate as usefully as you would like. Therefore,
the following sniplet is not violating C rules:
struct Foo { int *x; };
int foo (const struct Foo *p) { *(p-x) = 1; }
I don't think most languages propagate a const-like type. However, at
least
Hi,
On Thu, Jul 3, 2008 at 9:49 AM, Alberto Mardegan
[EMAIL PROTECTED] wrote:
If I proposed a patch which adds some const here and there, would that be
discarded a priori, or would it undergo a serious consideration?
I'm not a GTK maintainer, but one problem with this is backward
Havoc Pennington wrote:
I'm not a GTK maintainer, but one problem with this is backward
compatibility. Adding const can certainly break previously-working
code, especially C++ code.
This was an issued once faced when people migrated from KR C to ANSI C.
Nothing wrong with having a gconst
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
. But at this
point it's just too late to do it without breaking C++ programs that use
glib.
I might be ignorant on C++, but I don't see why this would break
anything. I'm not saying that g_hash_table_new() must return a const
GHashTable, but I'd like to be able to pass a const GHashTable
13 matches
Mail list logo
