Strange C developments
 

Hi Can anyone explain why C has added support for pthreads, while NOT
adding support for garbage collection? Convenient memory management would
be a much greater enhancement than replicating a perfectly good existing
library it seems to me.

Jase

Re: Strange C developments
 

Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection?

GC in 'C' is a non sequitur.

> Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>
> Jase
>

I think you want Java, then.

--
Les Cargill

Re: Strange C developments
 

"christian.bau" <christian.bau@cbau.wanadoo.co.uk> writes:
>And sorry to say, but C wasn't designed with garbage collection in
>mind.

I believe that a GC is both important and nice, a great productivity
enhancer, but for /higher-level languages/. C, on the other hand,
is /intended to be/ a low-level language. A language that adds just
a thin layer over the machine language. It is intended to be
a language to possibly /implement a garbage collector in/, when
it should be needed for a higher level language.

This is about layering: One does not complain that features of a
higher layer are not present in a lower layer, because this would
break the layering. When one wants to use Perl, Java, or LISP
instead of C, one is always free to do so.

There also is the Boehm-Demers-Weiser conservative garbage collector.

Re: Strange C developments
 

Jase Schick wrote:

> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.

Why do you believe that garbage collection should be added to the C
standard?


Rui Maciel

Re: Strange C developments
 

On 7/20/2012 4:14 PM, Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>

more people can agree on the behavior of a threading library than they
can on the behavior of a GC library?...

a few possible issues with a GC:
precise or conservative GC?
how does it represent references?
how does it interact with stack variables, global variables, or malloc?
does it simply behave like malloc, or does it also preserve type
information?
....

some of these issues would need to be addressed, and as-is, people get
by ok either using or implementing garbage-collection via libraries.

Re: Strange C developments
 

On Fri, 20 Jul 2012 21:14:50 +0000, Jase Schick wrote:

> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection?

GC requires a "walled garden", which C isn't.

You can't just "add support" for GC, you have to design the language
around the ability to enumerate references.

Re: Strange C developments
 

Le 20/07/12 23:14, Jase Schick a écrit :
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>
> Jase
>
The lcc-win compiler offers a garbage collector (Boehm's) in its
standard distribution. It is a very useful feature, used for instance in
the debugger of lcc-win, in the IDE and several other applications. Of
course it is used by many of the people that have downloaded lcc-win
(more than 1 million)

Re: Strange C developments
 

On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
> Le 20/07/12 23:14, Jase Schick a écrit :
>> Hi Can anyone explain why C has added support for pthreads, while NOT
>> adding support for garbage collection? Convenient memory management
>> would be a much greater enhancement than replicating a perfectly good
>> existing library it seems to me.
>>
>> Jase
>>
> The lcc-win compiler offers a garbage collector (Boehm's) in its
> standard distribution. It is a very useful feature, used for instance in
> the debugger of lcc-win, in the IDE and several other applications. Of
> course it is used by many of the people that have downloaded lcc-win
> (more than 1 million)

Do you never get tired of spamming this group with advertising for your
compiler?

Adding garbage collection would break a large amount of existing code.

Often the bottom couple of bits of pointers to memory with known
alignment properties will be used to store information (the pointer than
being and'd with ~0x3ul or similar prior to dereferencing).

Many code protection methods rely on storing pointers xor'd with an
obfuscating mask. GCs are not sophisticated enough to track such pointers.

And what is the gain? With careful programming, there is no need
whatsoever for this stupid overhead. Leave it for the kiddies programming
JAVA.

//QP

Re: Strange C developments
 

Le 21/07/12 12:23, Quentin Pope a écrit :
> On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
>> Le 20/07/12 23:14, Jase Schick a écrit :
>>> Hi Can anyone explain why C has added support for pthreads, while NOT
>>> adding support for garbage collection? Convenient memory management
>>> would be a much greater enhancement than replicating a perfectly good
>>> existing library it seems to me.
>>>
>>> Jase
>>>
>> The lcc-win compiler offers a garbage collector (Boehm's) in its
>> standard distribution. It is a very useful feature, used for instance in
>> the debugger of lcc-win, in the IDE and several other applications. Of
>> course it is used by many of the people that have downloaded lcc-win
>> (more than 1 million)
>
> Do you never get tired of spamming this group with advertising for your
> compiler?
>
> Adding garbage collection would break a large amount of existing code.
>

To port existing code to a GC environment you do not need to change a
single line. Just define malloc as gc_malloc and define free as a noop.


> Often the bottom couple of bits of pointers to memory with known
> alignment properties will be used to store information (the pointer than
> being and'd with ~0x3ul or similar prior to dereferencing).
>

??? That is not the case with the GC used by lcc-win.

> Many code protection methods rely on storing pointers xor'd with an
> obfuscating mask. GCs are not sophisticated enough to track such pointers.
>

Yes, that kind of code shouldn't be used with a GC.

> And what is the gain?

The gain is that instead of loosing endless hours tracking that dangling
pointer in the debugger you can concentrate on your application instead.


> With careful programming, there is no need
> whatsoever for this stupid overhead.

You fail to mention "With careful programming and not making any
mistake. NEVER. A single moment of inattention and you are screwed.


Leave it for the kiddies programming
> JAVA.
>

JAVA, Lisp, C++, C, all the languages that can be used ith a collector.

Re: Strange C developments
 

בתאריך יום שבת,21 ביולי 2012 11:23:52 UTC+1, מאת Quentin Pope:
>
>
> Often the bottom couple of bits of pointers to memory with known
> alignment properties will be used to store information (the pointer than
> being anded with ~0x3ul or similar prior to dereferencing).
>
> Many code protection methods rely on storing pointers xored with an
> obfuscating mask. GCs are not sophisticated enough to track such pointers..
>
Rarely do you need to do this sort of thing, particularly in a hosted environment.

The gain is that far too much C code is concerned with handling memory allocation failures and clean-up that can't happen. For instance user provides a list of filenames in a configuration file. I need to read them in and return as a list of strings. If a memory allocation failure occurs halfway through building the list, I've got to deallocate a half-built list, and return an error condition, probably a null pointer. The code to handle this willprobably be about half the function, even though if I've 4GB of memory installed, and the total allocation is 1000 bytes, the computer is more likelyto suffer an electrical failure than it is to run out of memory.

Thne you've got to write little function just to deallocate the list of strings, in normal use.

The reason I don't use garbage collection is a) it's non-standard and b) most garbage collectors are unacceptably inefficient for high performance routines. But it's a blessing from the coding angle.