«

"Dave Vandervies" <> wrote in message
news:bhbja5$5co$...
> In article <bh8phq$fis$>, Serve La <>
wrote:
>
> >It's almost (almost) getting funny, the resistance you people are showing
> >against GC. Files are used totally differently. I have never seen anybody
> >including myself chasing an "fclose" bug, or closing an invalid file
> >pointer.
>
> I have.
>
> And I'm not about to suggest that GC-style resource management would
> have made the code work, or even made the bug less of a problem.
> It definitely wouldn't've made it easier to find.
>
> There are more things in heaven and earth,
> Than are dreamt of in your philosophy.

Yes , I know that of course. But I was commenting on the fact that when
somebody proposes a useful feature and all answers he get are "but my files
are not cleaned up automatically" , "it can hide bugs in my algorithms" ,
"it does not work on platform xyz" , "now I can't do free(malloc(10));". Not
one positive answer. So the consensus among C people is that "GC is bad"?

"Andre" <> wrote in message
news:3f3a788b$...
> No.. *that* particular GC implementation is bad.. not GC itself.

The boehm collector? why?

No.. *that* particular GC implementation is bad.. not GC itself.

-Andre

Serve La wrote:
> "Dave Vandervies" <> wrote in message
> news:bhbja5$5co$...
>
>>In article <bh8phq$fis$>, Serve La <>
>
> wrote:
>
>>>It's almost (almost) getting funny, the resistance you people are showing
>>>against GC. Files are used totally differently. I have never seen anybody
>>>including myself chasing an "fclose" bug, or closing an invalid file
>>>pointer.
>>
>>I have.
>>
>>And I'm not about to suggest that GC-style resource management would
>>have made the code work, or even made the bug less of a problem.
>>It definitely wouldn't've made it easier to find.
>>
>>There are more things in heaven and earth,
>>Than are dreamt of in your philosophy.
>
>
> Yes , I know that of course. But I was commenting on the fact that when
> somebody proposes a useful feature and all answers he get are "but my files
> are not cleaned up automatically" , "it can hide bugs in my algorithms" ,
> "it does not work on platform xyz" , "now I can't do free(malloc(10));". Not
> one positive answer. So the consensus among C people is that "GC is bad"?
>
>

On Wed, 13 Aug 2003, Serve La wrote:
>
> "Andre" <> wrote in message
> news:3f3a788b$...
> > No.. *that* particular GC implementation is bad.. not GC itself.
>
> The boehm collector? why?

Not Boehm. Jacob Navia's particular interface to Boehm. (Of course,
maybe Boehm's GC is bad too; I'm not a GC expert.)

I already said this in a personal email exchange with Jacob, but
here's what I find annoying/incorrect about his GC:

1) GC in general does not fit into the C language.

Because the C standard does not require GC, it is expected that a
C program will be able to run properly with or without GC. If it
doesn't clean up its own mallocs, then it's not properly-written
standard C. And if a program *does* run correctly without GC, why
on earth would you *add* GC to it? It's just library bloat at
that point.

2) This particular GC has a non-standard interface.

Jacob's first suggestion was to #define malloc GC_malloc. That
is AFAIK an invocation of undefined behavior, and isn't guaranteed
to work unless it is surrounded by

#ifdef __THIS_COMPILER_HAS_GC__

- except that of course the macro __THIS_COMPILER_HAS_GC__ does not
exist, so we're stuck with testing something defined by lcc-win32
(and, we hope, *only* by lcc-win32).

A much better interface would have been a #pragma directive; for
example,

#pragma LCCWIN32_GC

which requires much less thought by the programmer *and* has a better
chance IMHO of passing muster with the standards police.

3) The original proposal had a bug in it.

This is the #define free(a) (a=NULL) thing that several people pointed
out. Sure, it's trivial to fix, but the fact that it was included in
the proposal at all indicated that maybe Jacob hadn't put as much thought
into his design as he could have.

4) Real Programmers(tm) don't do garbage collection.

This one is a stereotype, of course, but you should realize that a lot
of the regulars in c.l.c are (or seem to be) Real Programmers(tm).
They program in C because they like the fine control, the clean
interface, and the raw power that the language provides. Garbage
collection is an attribute of higher-level Quiche Eater languages like
Lisp and Java, and you just shouldn't expect a ticker-tape parade from
the C programmers when you try to introduce it into C. It's the
psychology of the thing. C's been around for more than 20 years now
without GC; if you want GC that bad, use a language that has it built
in. That's how it is.


That pretty much sums up the points I've seen against this GC.

HTH,
-Arthur

"Arthur J. O'Dwyer" <> wrote in message
newsine.LNX.4.55L-...
>
> On Wed, 13 Aug 2003, Serve La wrote:
> >
> > "Andre" <> wrote in message
> > news:3f3a788b$...
> > > No.. *that* particular GC implementation is bad.. not GC itself.
> >
> > The boehm collector? why?
>
> Not Boehm. Jacob Navia's particular interface to Boehm. (Of course,
> maybe Boehm's GC is bad too; I'm not a GC expert.)
>
> I already said this in a personal email exchange with Jacob, but
> here's what I find annoying/incorrect about his GC:
>
> 1) GC in general does not fit into the C language.
>
> Because the C standard does not require GC, it is expected that a
> C program will be able to run properly with or without GC. If it
> doesn't clean up its own mallocs, then it's not properly-written
> standard C. And if a program *does* run correctly without GC, why
> on earth would you *add* GC to it? It's just library bloat at
> that point.

With this logic you could say too:
1) library XYZ is not mentioned in the C standard
2) It is expected then, that any C program runs without the library XYZ
3) Therefore (!!!) library XYZ is BAD.

> 2) This particular GC has a non-standard interface.
>
> Jacob's first suggestion was to #define malloc GC_malloc. That
> is AFAIK an invocation of undefined behavior, and isn't guaranteed
> to work unless it is surrounded by
>
> #ifdef __THIS_COMPILER_HAS_GC__
>
> - except that of course the macro __THIS_COMPILER_HAS_GC__ does not
> exist, so we're stuck with testing something defined by lcc-win32
> (and, we hope, *only* by lcc-win32).

The standard interface for the GC in lcc-win32 is:

#include <gc.h>

The ONLY thing to do then is:

#ifdef __LCC__
#include <gc.h>
#endif

> 3) The original proposal had a bug in it.
>
> This is the #define free(a) (a=NULL) thing that several people pointed
> out. Sure, it's trivial to fix, but the fact that it was included in
> the proposal at all indicated that maybe Jacob hadn't put as much thought
> into his design as he could have.
>

As I told you the *standard* interface is to call GC_free(), i.e.
#define free GC_free

This is 100% compatible with the free() interface. BUT I think it is
better to use
#define free(a) (a=NULL)
since
1) This destroys the pointer to the freed memory
2) Doesn't call GC_free() eliminating any free() errors. Normally
you do not use free()

> 4) Real Programmers(tm) don't do garbage collection.
>
> This one is a stereotype, of course, but you should realize that a lot
> of the regulars in c.l.c are (or seem to be) Real Programmers(tm).

I see.

> They program in C because they like the fine control, the clean
> interface, and the raw power that the language provides. Garbage
> collection is an attribute of higher-level Quiche Eater languages like
> Lisp and Java, and you just shouldn't expect a ticker-tape parade from
> the C programmers when you try to introduce it into C. It's the
> psychology of the thing. C's been around for more than 20 years now
> without GC; if you want GC that bad, use a language that has it built
> in. That's how it is.

Look Arthur. As I told you I have an automatic drive. Many people are
real_drivers(tm)
and look at me with utmost comptent for saving me the effort of changing gears
several thousand times a day. I have seen with my own eyes a TAXI driver that
told me that.

"It doesn't hurt your hand at the end of the day?" I asked him.
Yes, he told me, but you know, this is driving, really, people that use
an automatic car are pimps.

I payed and left. The world is big and there must be people of all kinds
to fill it up.
Personally, I still use my automatic and if anybody calls me a pimp because
of that, I wouldn't care less.

Feel free to spend all that time debugging your manually done malloc/free
calls Arthur. It is your life, your programs.

But please do not try to forbid automatic garbage collection from the C language.
It is ridiculous, like if somebody would forbid automatic cars!!!

jacob

# one positive answer. So the consensus among C people is that "GC is bad"?

Never mistake the comp.lang.c clique for C people.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I'm not even supposed to be here today.

"Derk Gwen" <> wrote in message
news:...
> # one positive answer. So the consensus among C people is that "GC is
bad"?
>
> Never mistake the comp.lang.c clique for C people.

Well, I'd say there are a lot of pretty good and experienced C programmers
in here.

Arthur J. O'Dwyer wrote:
>
> Because the C standard does not require GC, it is expected that a
> C program will be able to run properly with or without GC. If it
> doesn't clean up its own mallocs, then it's not properly-written
> standard C.

There is a time and a place for C programs that clean up their
own mallocs. Long-running server processes, or user programs
that respond to an indefinitely long string of commands (text,
mouse-clicks, or brain waves, for all I care).

There is _also_ a time and a place for C programs that totally
ignore "memory leaks", and trust that the system will reclaim
any allocated memory when exit() is called. Obvious examples
are single-use programs on a "sufficiently large" machine,
or programs that do one thing and exit (e.g., *nix basename(1)).

Finally, many C programs are used in a context where any use
of malloc() itself is considered a bug, because there is no
guarantee of success, and success is mandatory. So of course
in this case there are no free()'s either.

Of course, none of this changes Arthur's conclusion, that
GC in C is a bad idea. People might be tempted to use it
in order to quickly (and without deep understanding) convert
programs conceived as "single-use on a sufficiently large
machine" into production code, but that is a horrible idea
for many more reasons than memory allocation. I'm all in
favor of quick prototyping, but the conversion from prototype
to production code is nothing to be taken lightly.

- Larry

# With this logic you could say too:
# 1) library XYZ is not mentioned in the C standard
# 2) It is expected then, that any C program runs without the library XYZ
# 3) Therefore (!!!) library XYZ is BAD.

The clique has in fact opined in the past that only legitimate functions are those
defined in the standard or defined in full. Reference to any other functions is deemed
off topic to reduce the cognitive load on the clique. The resulting flame wars do not
reduce the traffic, but rather increase it; topics that can be dealt with a simple
answer instead erupt into hundreds of posts over many weeks whining about off topicness.
(The clique is of course permitted to veer off topic.)

# > This is the #define free(a) (a=NULL) thing that several people pointed
# > out. Sure, it's trivial to fix, but the fact that it was included in
# > the proposal at all indicated that maybe Jacob hadn't put as much thought
# > into his design as he could have.
# >
#
# As I told you the *standard* interface is to call GC_free(), i.e.
# #define free GC_free

A typical clique response is to whine excessively about trivial issues. The idea being
to frustrate people outside the clique into silence.

--
Derk Gwen http://derkgwen.250free.com/html/index.html
I have no respect for people with no shopping agenda.

Derk Gwen wrote:
....
> A typical clique response is to whine excessively about trivial issues. The idea being
> to frustrate people outside the clique into silence.
I have the impression that momentary it is you, who is whining.

Jirka