|A Better C Language firstname.lastname@example.org (1994-06-08)|
|Re: A Better C Language email@example.com (1994-06-22)|
|Re: A Better C Language firstname.lastname@example.org (1994-06-24)|
|Re: A Better C Language email@example.com (1994-06-28)|
|From:||firstname.lastname@example.org (Steve Boswell)|
|Organization:||Universal Media Netweb|
|Date:||Wed, 22 Jun 1994 16:41:52 GMT|
email@example.com (Thomas Wang) writes:
>2.7. Freeing Memory
>The programmer need not free bctype objects. This
>responsibility is taken care by the Better C compiler. The
>object code generated by the compiler will free the memory that
>are no longer used.
>Therefore, the sample main program listed above will never run out of memory.
Adding garbage collection to C is a noble idea, but what do you do with
hairy pointer arithmetic that could be pointing to anything? I mean, just
imagine a "char *****", which could, at its various levels, be pointing to
arrays, single objects, allocated memory, stack buffers, etc. How are you
going to keep track of that? If you tag everything, you'll lose the
low-level look-and-feel of C.
IMHO, C is not really amenable to real object-oriented programming. C++
is a great example of that: the language is now more complex than Ada, and
shows no signs of letting up!
Personally, I prefer Beta -- it's mind-bogglingly flexible, and has
garbage collection. Its main drawback, as far as industry is concerned,
seems to be that it's not C. ;-)
Return to the
Search the comp.compilers archives again.