Talk:GLib

message: 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)
replies: text: 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)
replies: text: 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)
thread_title:  philosophy behind GLib? 

message: 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)
replies: text: I've just removed the list. bruce89 (talk) 23:51, 10 November 2009 (UTC)
thread_title: Wrong content

message: 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)
thread_title:  Type definitions 

message: 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)
thread_title: Weaknesses

message: Is there a historic ironic connection to the adjective glib?
62.119.167.36 (talk) 11:46, 9 February 2016 (UTC)
replies: text: '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)
thread_title:  glib reference to adjective? 

message: 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)
thread_title:  Dreadful Grammar