He estado leyendo código que usa gtk+ y he encontrado tipos como gboolean y gunichar .
Mientras pueda entender el punto de usar gunichar en lugar de wchar_t ( glib gunichar y wchar_t ), realmente no puedo entender el punto de usar gboolean en lugar de bool .
gboolean en lugar de bool ? ¿Hay algo más que tener cuidado con la consistencia del estilo del código? No sería tan extraño para mí si se usara para una consistencia general ( si uno decide usar GLib , preferirá usar los tipos definidos allí ). Sin embargo, el autor de ese código usa int en lugar de gint . ¿El autor está siendo descuidado?
Solo para agregar más detalles ( GLib oficial como referencia ):
gunichar se define como typedef guint32 gunichar
guint32 se define como typedef unsigned int guint32
gboolean se define como typedef gint gboolean
gint se define como typedef int gint
Uniformidad y mantenibilidad. Si en un momento determinado en el futuro se introduce un nuevo tipo utf8char , solo será cuestión de cambiar el typedef y volver a compilar, sin tener que pasar por miles de líneas de código para parchear cada uso.
Considere también que GLib está diseñado para funcionar en una amplia gama de compiladores, no todos totalmente compatibles con las últimas especificaciones. Por ejemplo, no se puede asumir la disponibilidad de los tipos bool , wchar_t y de tamaño fijo, ya que todos venían con C99 y C11. Además, el desarrollo de GLib comenzó en 1998 (como puede ver en el gráfico de colaboradores ), cuando C99 aún estaba en borrador y esas características ni siquiera eran estándar.
Recientemente descubierto, no se trata solo de consistencia; en realidad, hay una advertencia cuando se trata de plataformas big endian .
En las plataformas Big Endian probadas hasta el momento (PowerPC32, Sparc64, etc.), g_option_context_parse() fallaría al manejar el argumento declarado con C99 _Bool , como si las opciones relevantes fueran completamente ignoradas. Cambia a gboolean y todo vuelve a funcionar. Este problema no está presente en las plataformas little endian.
No estoy seguro de si es un comportamiento intencional, pero el análisis interno de los argumentos de tipo G_OPTION_ARG_NONE se maneja con gboolean , que es equivalente a un número entero nativo en términos de tamaño de byte ocupado, mientras que _Bool ocupa solo 1 byte. Probablemente eso explique el problema en el entorno big endian.