|This is the talk page for discussing improvements to the GLib article.
This is not a forum for general discussion of the article's subject.
|This article is of interest to the following WikiProjects:|
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?
- 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 184.108.40.206 (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)
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)
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).
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)
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)
glib reference to adjective?
Is there a historic ironic connection to the adjective glib?
- '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)