Talk:GLib

philosophy behind GLib?

Isn't there some sort of red-line behind Glib's development? A constant goal? Is it crossplatform development? or giving C a semi Object Orientated functionality? Perhaps more efficient use of memory?

Anything? —The preceding unsigned comment was added by 217.121.220.121 (talk) 15:52, 27 December 2006 (UTC).

Its goal is for cross platform compatibility. If you write a C program can you do everything by only making c stdlib and glib calls, which makes your application cross platform with soldom modifications needed. glib provide no gui cross platform functions, gui functions are gtk+. —Preceding unsigned comment added by 155.144.40.31 (talk) 03:05, 23 January 2009 (UTC)

Among others. It also provides data structures for higher level programming, a pretty full-grown (boasty, don't write that in the article!) thread model including some message passing, mutex, safe (?) memory handling and such. IMHO the stmt that glib is an alternative to STL seems to be realistic, as well as an alternative to some important parts of Java's JDK libs, although of course there are no GUI in glib, since that belongs to GTK+ and others. ... said: Rursus (bork²) 17:23, 17 May 2009 (UTC)

Wrong content

That list of scalar datatypes should not be in this article. Any programming language contains the counterpart of those datatypes. For replacement, the article should just claim:

glib provides scalar datatypes that have a specified range in opposition to C:s scalar datatypes

The important features of glib is what is stubbily described in section Features: aggregate types like strings, hashes, generalized streams (f.ex. file/socket/pipe), and a lot of stuff transforming C from among one of the lowest level processor independent languages, to a pretty high level language. ... said: Rursus (^mbork³) 07:43, 28 August 2009 (UTC)

I've just removed the list. bruce89 (talk) 23:51, 10 November 2009 (UTC)

Type definitions

The article contained the following:

On an elementary level GLib provides type definitions replacing the C primitive types char, int, float, and so on in order to improve portability; since the C standard doesn't define any minimal byte size of those types

This is, in fact, entirely false; "char" defines the size of a "byte" in C, and is as such always one byte, and int and float both have defined minimum ranges, although they can be only a single byte if a "byte" is defined to be particularly large (memory only indexable in large amounts can mean a large "byte" is required, as one of the requirements of C is that the entirety of memory can be indexed by byte).

As what GLib actually does in this regard is unclear, and the rationale written here is totally wrong, I have simply removed it. --Namegduf Live (talk) 18:25, 20 May 2010 (UTC)

Weaknesses

There had been a section with this heading, noting :GLib's memory allocation function, g_malloc(), will cause the program to exit unconditionally upon memory exhaustion, unlike malloc, C++ new, and other common memory allocators which allow a program to cope with out-of-memory situations without simply crashing., An anonymous author removed this with with commentary about g_mem_set_vtable(), but this doesn't allow a program to adapt to memory constraints within the current call. Using g_try_malloc is the only direct answer, but even that has deep issues covered in http://code.google.com/p/chromium/issues/detail?id=51286#c27 - GLib's fundamental bias towards crashing on OOM still warrants inclusion, especially for those contemplating libraries to use in projects with high reliability requirements and constrained memory. What's a fair way to describe such a problem, when even those closer to GLib development seem to be at philosophical odds? C. Alex. North-Keys (talk) 22:47, 10 July 2013 (UTC)

Confusing GLib with glibc

I find it profoundly confusing that this page tries to point out that GLib and glibc (GNU C Library) are different things, yet illustrates the structure of GLib using a chart explaining only glibc, with the description

As the GNU C Library serves as a wrapper for Linux kernel system calls, so do the libraries bundled in GLib (GObject, Glib, GModule, GThread and GIO) serve as further wrappers for their specific tasks.

Essentially, we're saying "Please note that A is not B, but have a look at this chart of B to understand what A is." Personally, when I reached the GLib page the first thing that caught my eyes was "GNU C Library" from the image. I had to read the fine print to understand that my original impression was wrong. What's the rationale for keeping the image there? --τις (talk) 19:21, 27 August 2014 (UTC)

This really confused me too. Given that no one has justified it at all, I'm going to remove it. 38.104.182.182 (talk) 13:59, 2 September 2016 (UTC)

I am not sure that a similar text to the one accompanied the problematic image should not be in the article.

libraries bundled in GLib (GObject, Glib, GModule, GThread, and GIO) serve as further wrappers, for the underline system library, for their specific tasks

, as it may help less technical readers grasp what the article is about. 147.161.8.4 (talk) 14:07, 20 May 2021 (UTC)

glib reference to adjective?

Is there a historic ironic connection to the adjective glib?

62.119.167.36 (talk) 11:46, 9 February 2016 (UTC)

'don't suppose so : most everything GNOME or GTK start with a G ; "lib" is most common for "library" in the programming world. Hyphenating such as "G-lib" is too much typing ; besides, hyphenated components stack up very quickly in program names versioning, no need to add to that. --Jerome Potts (talk) 02:16, 30 December 2016 (UTC)

Dreadful Grammar

The grammar in the article is just dreadful. For example, consider this statement that has 3 commas and doesn't make sense:

"The GLib package consisted of five libraries, but they were all merged into one library, since then named simply GLib, and are no longer sustained as standalone libraries." — Preceding unsigned comment added by 81.187.174.43 (talk) 12:12, 1 May 2023 (UTC)