> Also its really not something only LO does:
> 
> http://www.gtk.org/api/2.6/glib/glib-Basic-Types.html 

Whoa, stop there.

I can assure you that C code written in the "GLib/GTK+ style" definitely does 
*not* use gint32 or guint32 all over the place, if that was what you were 
hinting at.

gint32 and guint32 are used only in very specific cases where the code 
explicitly wants to use 32 bits on all platforms in all cases, like marshalling 
to/from some serialized data structure.

Otherwise it's int or its equivalent gint that is used. And yes, many of these 
people do care a lot about warning-free code, for example compiling GIMP is not 
supposed to produce warnings, as far as I know. 

gint64 and guint64 are used in places where it is known that 32 bits is not 
enough, even if it isn't specifically exactly 64 bits that is necessarily 
wanted. Yes, that is wrong: Perhaps, some day, when we have machines where 
128-bit integral types are equally natural and fast as 64-bit ones are today, 
this will be seen as a bad decision, and what should have been used instead 
would be some "gint64orlonger" type.

(I guess I should point out that GLib and the GTK+ stack are portable only to 
platforms where int is at least 32 bits.)

And yes, many do feel that the typedefs gint, guint, gchar and guchar in GLib 
are a bit silly, as it is 100% equivalent to just use int, unsigned int, char 
or unsigned char instead. Others do like to use them just for visual 
consistency in the code. Myself, I don't care that much, I use whatever the 
surrounding code does, and if writing completely new GTK+ code (which I hardly 
ever do) I use just int and char and not gint or gchar.

(With "GLib/GTK+ style I mean the style used by people that have been involved 
in writing and designing the GTK+ stack themselves, a typical example would be 
GIMP.)

--tml


_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to