Re: "Criticism of the C programming language ??????"

jacob navia wrote:
Richard Heathfield wrote:
Keith Thompson said:

<snip>
So it appears that I was mistaken. The point I was missing (or had
forgotten,
whatever) is that GC only affects memory allocated by GC_malloc(). Even
if GC is enabled, a block of memory allocated by malloc() will never be
garbage-collected.

That kinda defeats the point of AGC, since it means that you can't use a third-party library with the same devil-may-care attitude to GC that an AGC would invoke in your own code.

I have a parse error with the above sentence. Maybe because I do not see
what is an AGC. Is it "A garbage Collector" ?

Let's suppose that. Then, I still do not understand that when you are using the GC in YOUR application you expect somehow that automagically
other applications and third party libraries will use it too?

That would be strange from Heathfield, that otherwise never does
such huge assumptions...

You have to read the lib docs to find out how to manage the memory. (Personally I don't see this as a trial, but it's clearly a weakness in the argument for AGC.)

Of course you have to read the docs before using a third party
library. And you use it as documented. If the library allocates
memory and expects the user should free it you do so. And you
would have to do that GC or not GC!

I fail to understand how someone that knows how programming works expects that the GC will soleve magically all memory allocation problems
using unspecified third party libraries!

This sub-thread started with KT saying that garbage collection requires semantic changes to the language. I've not thought about it in detail, but it seemed likely to me that that was true. You responded by saying that "garbage collection is just a library". I didn't see how that could be true since, like KT, I was thinking of garbage collection integrated into the language itself. In a later message, after a burst of silly and pointless sarcasm, you were persuaded to explain that you were talking about an additional memory allocation library which would support garbage collection for memory it controlled.

This is very different from garbage collection as part of C itself, but might certainly be useful to people who like garbage collection. Its not being an integral part of C has the advantage that it doesn't introduce backward compatibility issues and could be added fairly painlessly; however, it has the disadvantage that it doesn't apply to all memory allocations, and if the memory has been allocated by a third-party library it is not immediately obvious whether or not that memory will be garbage collected. Having two different types of allocated memory makes things more complicated, and puts more requirements on the specification of libraries.

If garbage collection were 'added to C' the programmer would expect that all dynamically allocated memory would be garbage collected. Your proposal doesn't do that, which is a disadvantage. RH was pointing out that disadvantage; that's all. Most proposals have advantages and disadvantages. Compared to adding garbage collection to C itself, your proposal has the big advantage that it doesn't introduce backward compatibility issues, but at the cost that the programmer can't simply assume that garbage collection applies to all dynamically allocated memory.

Whether or not your proposal ever becomes part of the C definition depends on how many people want garbage collection in C enough to make a fuss about it, and how many of those would think your approach a good way to do it. For those who don't care about garbage collection, I can't immediately see much objection to the proposal, other than its making the library definition bigger, and potentially requiring people to work with garbage collection in the future if other libraries make use of it.
.

Relevant Pages

  • Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
    ... My problem with it is the lack of a garbage collection. ... pretty much have memory bugs, ... Modern GCs are much faster than older ones, ... Concurrent GCs exist, nevermind GCs that play fairly nicely with concurrent application code. ...
    (comp.programming)
  • Re: allocating memory.
    ... So what would be the ASM equivalent of new memory ... Memory allocation is primarily an OS responsibility, ... OSes are almost certainly responsible for memory ...
    (alt.lang.asm)
  • Re: Doubts on Defining and declaring variables
    ... 1.Dim iage ... and allocate memory for each of them ... My understanding:-Still No memory allocation done at this ... Now since string is assigned to iage,So will ...
    (microsoft.public.scripting.vbscript)
  • Re: Article of interest: Python pros/cons for the enterprise
    ... from many articles and postings across the internet memory management ... There are other downsides to garbage collection, ... not the way it goes in practice nowadays, ...
    (comp.lang.python)
  • Re: xmalloc string functions
    ... require memory allocations depending on the way the system works. ... Not enough context for most real-world applications to ... It is /more/ reliable to routinely auto-save the user's work (as you ... particularly if your auto-save code is robust against memory allocation ...
    (comp.lang.c)