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. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||
|
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).
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:
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).
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)
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
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)
Is there a historic ironic connection to the adjective glib?
62.119.167.36 ( talk) 11:46, 9 February 2016 (UTC)
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)
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. |
Article policies
|
Find sources: Google ( books · news · scholar · free images · WP refs) · FENS · JSTOR · TWL |
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||
|
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).
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:
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).
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)
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
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)
Is there a historic ironic connection to the adjective glib?
62.119.167.36 ( talk) 11:46, 9 February 2016 (UTC)
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)