Re: Lcc-win32 extensions to C
- From: "SuperKoko" <tabkannaz@xxxxxxxx>
- Date: 1 Jun 2006 05:44:38 -0700
jacob navia wrote:
It doesn't mean that it must be different for the common part of C andPlus, as far as possible, if would be good to follow approximatively
the same (simplified) rules than C++.
There are no classes in C, so this is completely different.
C++.
There are already too many stupid useless historical incompatibilities
between C and C++.
I mean that ideally, a C++ program which uses only C
features+overloading (without any class), should behave the same when
compiled with a C++ compiler or a C compiler.
Since I'm mainly a C++ programmer, I can't say if it is true... But, inHowever, it worth noticing that, GC heaps tend to use more memory than
non-GC'ed heaps, because the memory is not released as soon as it
should be.
Yes, but if you do not use GC, you allocate more memory than needed to
avoid calling malloc too often...
C++ I don't allocate more memory than needed (and instead of using a
O(n*log(n)) realloc mechanism when I need growing array, I use
std::deque)!
jacob navia wrote:
But, since heap technologies are simplier than garbage collector,You also know that a heap wastes some memory (especially if there is
fragementation).
And that several heaps wastes even more memory (that's why when linking
two C programs that use two different heaps, there is a greater waste
of memory).
Using a non-GC'ed heap+ a GC'ed heap requires also more memory...
But, if there are several GC'ed heap+several non-GC'ed heaps, it will
waste quite much memory..
Furthermore, heaps (for instance, under Linux) are (more or less) often
shared by several compilers, on a given platform. With Garbage
Collector, since GC technologies are much more advanced than simple
heaps, I fear that any compiler vendor will use a different GC, because
they can have specific high-tech optimizations... Worst, I feat that
compiler vendors will use new GC at each major release of their
compiler....
What means that linking many shared libraries which have been compiled
by many different compilers (or compiler versions) will introduce .....
an huge number of GC'ed heaps!
Maybe, but this is the same today: linking together several libraries
each with its own malloc implementation produces the same result.
compiler vendors (I guess) may tend to write their own garbage
collectors (and claim that their GC is "better" than others) instead of
using the OS-provided (or commonly used) heap.
And, since the old heap is still present, it will multiply by (at
minimum) a factor 2, the number of heaps.
Note also that if GC_Malloc is the only way of invoking the garbage
collector, the program will either contain memory leaks (i.e. memory
which is not released during a lot of time), or dummy calls to
GC_Malloc, which would allocate only 1 or 0 byte, in order to "invoke"
the garbage collector.
jacob navia wrote:
SuperKoko wrote:It doesn't mean that it should be put in the language.
4) I fear one thing : that the C language be cut in two different
languages : C with GC, and C without GC...
You know that interfaces are very different when using garbage
collection... Even if it may be formalized by a small change in the
standard, it is a huge change in the daily code...
I fear that for reasons of style (or for reasons mentioned above),
there will be two different styles of libraries:
- Old-style libraries, not using garbage collection at all.
- New-style libraries, heavily using the garbage collected heap.
Well, many people use the GC today. GC is not new, it is a concept in
data processing since the seventies or earlier...
Ah. I thought that you posted that here as a proposal for a standard
You see that garbage collection has several major problems. Even if
some of them can be reduced or removed, I don't think it is a good idea
to add that to the C standard.
I do not think that anything needs to be added to the standard actually.
The GC is an external library, that's all.
No need for any language modifications.
comitee.
But if it is only a proposal for compiler vendors, there is no problem.
Anyway, GC benefits would be very small in C, because:
GC only solve (and not well) the problem of memory leaks (and not other
resource leaks).
In particular, it means that once an object has (internally) a handle
to a non-pure-memory object, it is not a pure memory object, and can't
be put in the GC heap.
So, the GC is only for pure memory objects, which only totally live in
one GC heap.
Furthermore, with actual GC technologies (even if they claim that it
works better than manual heap management) it doesn't prevent memory
leaks (especially if invokation is "manual")... Actually GC'ed programs
are full of memory leaks... But the garbage collector *collects* them.
Actually I think that it should be named a "memory leak collector".
Furthermore, if the GC is conservative, it's very easy to forget
nullifying a dead reference... For instance, when writing a stack class
containing pointers to GC heap, you'll have to nullify the pointer when
removing the object from the stack, otherwise there would be a memory
leak.
But as far as the collector is not conservative, but requires explicit
management of strong references, there is no problem (anyway I think
that a conservative collector is a bad idea in C, as I described in my
previous post).
So, GC doesn't really solve the memory leak problem for platforms where
memory is a precious resource.
I think that if several vendors use GC and that library use GC, it will
complicate memory handing instead of simplifying it (because GC is
complex to handle on library boundaries).
If you like GC, you can write a GC on popular platforms... I think that
it will be far more easy to use than if it is integrated by compiler
vendors, because the same GC will be used by all programs of the
platform.
jacob navia wrote:
I have presented this document to the C language discussion group, whereNot very astonishing... C programmers are very conservative (and that's
it received flames to no end. I noticed however, that many people
expressed support, and at the same time, the downloads for lcc-win32
that were more or less stable at 300-500/day skyrocketed to 1800/day
after that discussion.
a good thing).
C++ is less conservative... If C was not so stable it would have become
C++.
But C is still a very interesting language because:
It is very stable and thus, very available on all platforms.
There are a lot of tools (lint & others, for instance) for C, because
the language is very stable and quite simple (thus simple to parse).
Since C89 is very portable and works well, C99 has been only slowly
adpoted by compilers... Because for most people C89 is better. They
prefer to have all advantages of a stable simple language, instead of
having a few non-vital extra features.
In that sense, C89 is an extremely successful norm. It has been so
widely adopted that even the new C99 norm is slow to replace it.
Stability and simplicity is the strength of C (note that this sentence
comes from a C++ programmer which likes both C and C++).
I think that it explains why C programmers don't like that their
language change... Otherwise these C programmers would have become C++
programmers a long time ago.
C++ is more likely to adopt changes. Moreover such things like
non-conservative GC, are easier to adopt in C++.
.
- Prev by Date: Re: value of an assignment expression, revisited
- Next by Date: Re: value of an assignment expression, revisited
- Previous by thread: Re: value of an assigment expression
- Next by thread: Defect Report: String literals can not be used to initialize static compound literals?
- Index(es):
Relevant Pages
|
