Re: A Better C Language

I wrote:
>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.


Steve Boswell (whatis@primus.com) wrote:
>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.


By default, only Better C objects are tagged, and garbage collected. C data
structures are not garbage collected. Therefore the "char *****" pointer
will still behave the same as before. All the ordinary C features still work
in the same way. I think this scheme is a good combination. The programmers
will use the garbage collected class library to implement the modeling. For
low level I/O stuff, C function calls and C data structure will run pretty
efficiently.


>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!


To me, 4 features are required to do a good class library.


1. GC
2. Exception handling
3. Late binding functions
4. Some sort of class structure


These are my order of importance. (3) and (4) allows you to build a class
library. (1) and (2) allows you to build a good library in general.


    -Thomas Wang (Computing work increases system entropy.) wang@cup.hp.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.