|A Better C Language email@example.com (1994-06-08)|
|Re: A Better C Language firstname.lastname@example.org (1994-06-22)|
|Re: A Better C Language email@example.com (1994-06-24)|
|Re: A Better C Language firstname.lastname@example.org (1994-06-28)|
|From:||email@example.com (Thomas Wang)|
|Date:||Fri, 24 Jun 1994 00:44:14 GMT|
>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 (firstname.lastname@example.org) 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
>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.
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.) email@example.com
Return to the
Search the comp.compilers archives again.