Smart Pointers: Is there something similar to smart pointers in C?

[MotoK]

Hi Experts,
I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

Regards
MotoK

[jacob navia]

MotoK a écrit :

Hi Experts,
I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

Regards
MotoK

There is something much better:

a garbage collector.

Using a garbage collector obviates the need for smart pointers,
constructors, destructors, weird language constructs, etc etc.

The constructors are again what they should always have been:
a function that is written when needed to initialize a data structure.
The destructors aren't needed in most cases since memory is
automatically reclaimed.

The most popular garbage collector is Boehm's one. Some compilers like
lcc-win32 provide a GC in the standard distribution. Other compilers
support it, notably GCC, and it can be used in any situation.

jacob

[Bill Pursell]

jacob navia wrote:

MotoK a écrit :

I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

There is something much better:
a garbage collector.

Which doesn't exist in standard C. lcc-win32 may provide
one, but it isn't standard C and it's generally a bad idea
to rely on a GC. If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.) The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Using a garbage collector obviates the need for smart pointers,
constructors, destructors, weird language constructs, etc etc.

A garbage collector *is* a "weird language construct".

The most popular garbage collector is Boehm's one. Some compilers like
lcc-win32 provide a GC in the standard distribution. Other compilers
support it, notably GCC, and it can be used in any situation.

I'm not aware of gcc support for a garbage collector for C. It
supports
garbage collection for objective-C, but I don't believe it provides
it for C.

--
Bill Pursell

[jacob navia]

Bill Pursell a écrit :

jacob navia wrote:

>>MotoK a écrit :

>>>I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

There is something much better:
a garbage collector.

Which doesn't exist in standard C. lcc-win32 may provide
one, but it isn't standard C and it's generally a bad idea
to rely on a GC. If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.)

Yes of course!

C is for "macho" programmers that drink beer and
are just backwards.

This is of course YOUR opinion. I beg to differ.

The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

If we have computers is for THEM to do the mind numbing work,
not me. I do not try to outsmart a computer by
using MY brain to do THEIR work!

>

>>Using a garbage collector obviates the need for smart pointers,
constructors, destructors, weird language constructs, etc etc.

A garbage collector *is* a "weird language construct".

Excuse me but you are dead wrong:

prototype:

void *GC_malloc(size_t);

usage:

char *buffer = GC_malloc(BUFSIZ);
WHAT is a "weird language construct" in there ???

The garbage collector imposes absolutely no
new language changes at all. You just use GC_malloc
instead of malloc, forget about free and link with
the provided library.

All this is 100% standard C.

>

>>The most popular garbage collector is Boehm's one. Some compilers like
lcc-win32 provide a GC in the standard distribution. Other compilers
support it, notably GCC, and it can be used in any situation.

I'm not aware of gcc support for a garbage collector for C. It
supports
garbage collection for objective-C, but I don't believe it provides
it for C.

The garbage collector is "language agnostic" and will work for C,
C++ or objective C in the same fashion.

>
--
Bill Pursell

[Rod Pemberton]

"Bill Pursell" <bi**********@gmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.) The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Everyone here says that. I like that ideology and want to agree with that.
But, apparently, it is a falsehood. If programmers were responsible, no
one here would be complaining about fgets and sprintf buffer overflows,
needing restrict pointers, free not setting the pointer to NULL, ptrdiff_t's
insufficient range, undefined behavior for out-of-bounds pointers, or any
other limitation, bug, or idiosyncratic feature of the C language. There'd
be no need for snprintf, strlcat, or garbage collection. Yet this group is
harrassed by the persistent complaints of dozens of self-proclaimed experts
about those and other problems. If I'm to believe the "experts," I have no
choice but to conclude that it is false to say the C programmers are
responsible or "smart" enough to keep track of those things by themselves.
Rod Pemberton

[Martin Ambuhl]

jacob navia wrote:

C is for "macho" programmers that drink beer and
are just backwards.

More to the point, comp.lang.c is for the C programming language. It is
not, as Jacob imagines, here for him to advertise the virtues of the
non-C language his product supports.

>
This is of course YOUR opinion. I beg to differ.

Of course, it is your own asinine statement with which you "beg to
differ." Ascribing it to others is only another instance of your
dishonesty. No one other than Jacob navia has asserted 'C if for
"macho" programmers that drink beer and are just backwards.' Jacob is
arguing with himself. Both Jacobs will, of course, lose.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

C is for "macho" programmers that drink beer and
are just backwards.

This is of course YOUR opinion. I beg to differ.

That is nobody's opinion, and it has no resemblance to anything that
anyone in this thread has written. (jacob likes to make up nonsense
about what he thinks other people think. I've given up thinking that
he's ever going to stop this rude and dishonest behavior.)

[...]

The garbage collector imposes absolutely no
new language changes at all. You just use GC_malloc
instead of malloc, forget about free and link with
the provided library.

All this is 100% standard C.

[...]

The garbage collector is "language agnostic" and will work for C,
C++ or objective C in the same fashion.

Every time jacob brings this up, he neglects to mention that garbage
collection can, in some circumstances, break strictly conforming code
that would work in the absence of garbage collection. GC works only
if all pointers are visible to the garbage collector in memory or
registers. For most code, perhaps even the vast majority, this is not
an issue. But if a non-GC C program that uses malloc() and free()
either writes a pointer value to a file (and reads it back during the
same execution of the program) or breaks down a pointer value into
bits or bytes (think about in-memory compression or encryption), the
pointer is guaranteed to be valid once the pointer value put back
together. With garbage collection, the GC is likely to assume that,
since it can't see the pointer, the memory it points to can be
deallocated, making the pointer invalid.

It's probably easy enough to avoid this, but it's important not to
just ignore the issue.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Heathfield]

jacob navia said:

MotoK a écrit :

>Hi Experts,
I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

Regards
MotoK

There is something much better:

a garbage collector.

Wrong again. C provides no such thing.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Rod Pemberton said:

"Bill Pursell" <bi**********@gmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

>If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.) The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Everyone here says that. I like that ideology and want to agree with
that.

Feel free.

But, apparently, it is a falsehood. If programmers were responsible, no
one here would be complaining about fgets and sprintf buffer overflows,

Wrong. The responsible programmers are the ones who know about these issues
(not that fgets is particularly vulnerable to buffer overflows as long as
you tell it the truth), and they can frequently be heard warning other
people about those issues, but they don't /complain/ about them. They write
their code defensively.

needing restrict pointers,

I've never seen a good justification for such a need.

free not setting the pointer to NULL,

It would be nice, but it's no big deal.

ptrdiff_t's insufficient range,

Since I hardly ever use it, why should I care?

undefined behavior for out-of-bounds pointers,

The solution to that is easy. Keep your pointers under control.

or any
other limitation, bug, or idiosyncratic feature of the C language.

Oh, come on - asking C programmers not to complain about C would be like
asking Formula 1 drivers not to complain about Formula 1 cars.

There'd
be no need for snprintf, strlcat, or garbage collection.

I have not yet seen a convincing argument that any of these is needed.
Certainly I've never needed them.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[jacob navia]

Rod Pemberton wrote:

"Bill Pursell" <bi**********@gmail.comwrote in message
news:11**********************@i42g2000cwa.googlegr oups.com...

>>If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.) The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Everyone here says that. I like that ideology and want to agree with that.
But, apparently, it is a falsehood. If programmers were responsible, no
one here would be complaining about fgets and sprintf buffer overflows,
needing restrict pointers, free not setting the pointer to NULL, ptrdiff_t's
insufficient range, undefined behavior for out-of-bounds pointers, or any
other limitation, bug, or idiosyncratic feature of the C language. There'd
be no need for snprintf, strlcat, or garbage collection. Yet this group is
harrassed by the persistent complaints of dozens of self-proclaimed experts
about those and other problems. If I'm to believe the "experts," I have no
choice but to conclude that it is false to say the C programmers are
responsible or "smart" enough to keep track of those things by themselves.
Rod Pemberton

I some simple setups or with a lot of effort, C programmers
will eliminate most of the problems associated with manual garbage
collection.

Eliminating 100% of all malloc/free problems is extremely
difficult and takes an incredible attention for mind-numbing
DETAILS that take time from other, much important
tasks.

The GC is not a cure-all for all memory management problems, and its
use depends of the application, but it is an ERROR to
dismiss it at the start, simply because the C standard doesn't
mention it.

The C standard mentions gets() asctime() and many other functions that
shouldn't be used at all.

This "backwards" view of the C language is promoted here
by some people, even if, as you point out, it has never worked
well.

I have another opinion.

My compiler system is deningrated here by those same people because
of its forward looking nature

http://www.cs.virginia.edu/~lcc-win32

[jacob navia]

Martin Ambuhl wrote:

jacob navia wrote:

>C is for "macho" programmers that drink beer and
are just backwards.

More to the point, comp.lang.c is for the C programming language. It is
not, as Jacob imagines, here for him to advertise the virtues of the
non-C language his product supports.

>>
This is of course YOUR opinion. I beg to differ.

Of course, it is your own asinine statement with which you "beg to
differ." Ascribing it to others is only another instance of your
dishonesty. No one other than Jacob navia has asserted 'C if for
"macho" programmers that drink beer and are just backwards.' Jacob is
arguing with himself. Both Jacobs will, of course, lose.

Saying that somebody that uses a GC should not program in C is
this "macho" attitude, that thinks that avoiding tools,
relying on the programmer never making an error, is THE
right way to develop software.

This attitude (only use malloc/free) closes itself to
technical improvements of the run time environment
without any reason or argument, "just because I never do any
mistakes"...

jacob

[jacob navia]

Richard Heathfield wrote:

Rod Pemberton said:

>>"Bill Pursell" <bi**********@gmail.comwrote in message
news:11**********************@i42g2000cwa.google groups.com...

>>>If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.) The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Everyone here says that. I like that ideology and want to agree with
that.

Feel free.

>>But, apparently, it is a falsehood. If programmers were responsible, no
one here would be complaining about fgets and sprintf buffer overflows,

Wrong. The responsible programmers are the ones who know about these issues
(not that fgets is particularly vulnerable to buffer overflows as long as
you tell it the truth), and they can frequently be heard warning other
people about those issues, but they don't /complain/ about them. They write
their code defensively.

Yes of course, and they never make mistakes, never forget to free
a buffer and free it only once, never forget anything always right
like that programmer wonder Mr Dan Pop that asserted that he had
never had a crash ...

Well, I am not that kind of person. I DO make mistakes,
I find mind-numbing chores like keeping track of each and every
buffer in my programs a BORING and STUPID activitty that
can be much better done by the machine!!!

>

>>needing restrict pointers,

I've never seen a good justification for such a need.

Of course, easy of programming just doesn't arrive to your
consciousness as a REAL NEED

>

>>free not setting the pointer to NULL,

It would be nice, but it's no big deal.

>>ptrdiff_t's insufficient range,

Since I hardly ever use it, why should I care?

You never use ptrdiff_t, never forget anything when using free()
yes, YOU are perfect Heathfield, I am not.

>

>>undefined behavior for out-of-bounds pointers,

The solution to that is easy. Keep your pointers under control.

So easy said but so difficult to do in practice Heathfield.

Let's take a BUG of yours then:

In your book "C unleashed" you assume that sizeof(int) == sizeof(void *)
in page 352 and following. And you did not realize it till now maybe.

I have the 2000 edition, maybe you did get a new one but in any case
that BIG BUG is in there, without any disclaimer Heathfield.

Please, do not assume that you are perfect.

>

>>or any
other limitation, bug, or idiosyncratic feature of the C language.

Oh, come on - asking C programmers not to complain about C would be like
asking Formula 1 drivers not to complain about Formula 1 cars.

>>There'd
be no need for snprintf, strlcat, or garbage collection.

I have not yet seen a convincing argument that any of these is needed.
Certainly I've never needed them.

You do NOT need snprintf... nice. How do you do snprintf then?

(just curious)

<snip>

[Richard Heathfield]

jacob navia said:

<snip>

Eliminating 100% of all malloc/free problems is extremely
difficult

Not for everybody.

<snip>

The GC is not a cure-all for all memory management problems, and its
use depends of the application, but it is an ERROR to
dismiss it at the start, simply because the C standard doesn't
mention it.

Nobody here is dismissing automatic garbage collection, and it is an error
for you to claim that they are. What is being dismissed is the claim that C
provides automatic garbage collection, because the claim is false.

The C standard mentions gets() asctime() and many other functions that
shouldn't be used at all.

True, but irrelevant.

This "backwards" view of the C language is promoted here
by some people, even if, as you point out, it has never worked
well.

This "backwards" view of comp.lang.c is promoted here by some people even
if, as I point out, it has never worked well.

I have another opinion.

Gosh.

My compiler system is deningrated here by those same people because
of its forward looking nature

No, your compiler system is not denigrated here. What is denigrated here is
your apparent inability to separate the idea of "C" from the idea of
"lcc-win32". The distinction is an important one.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>[...] The responsible programmers are the ones who know about these
issues (not that fgets is particularly vulnerable to buffer overflows as
long as you tell it the truth), and they can frequently be heard warning
other people about those issues, but they don't /complain/ about them.
They write their code defensively.

Yes of course, and they never make mistakes, never forget to free
a buffer and free it only once, never forget anything always right
like that programmer wonder Mr Dan Pop that asserted that he had
never had a crash ...

Every programmer makes mistakes. But, as mistakes go, mistakes involving
dynamic memory allocation are amongst the easier ones to fix.

Well, I am not that kind of person. I DO make mistakes,

So does everybody.

I find mind-numbing chores like keeping track of each and every
buffer in my programs a BORING and STUPID activitty that
can be much better done by the machine!!!

Then by all means use automatic garbage collection, if you wish. Your right
to do that is not in question. What is in question is your claim that C
provides it.

>>

>>>needing restrict pointers,

I've never seen a good justification for such a need.

Of course, easy of programming just doesn't arrive to your
consciousness as a REAL NEED

I find programming reasonably easy without restrict pointers. But I'm open
to persuasion. What value do they add, that will make my life easier?

>>>free not setting the pointer to NULL,

It would be nice, but it's no big deal.

>>>ptrdiff_t's insufficient range,

Since I hardly ever use it, why should I care?

You never use ptrdiff_t,

Do you really not understand the difference between "hardly ever" and
"never"?

never forget anything when using free()

I have never claimed that. I do claim, however, that it's not a huge
problem.

yes, YOU are perfect Heathfield, I am not.

I have not claimed perfection, but it is gratifying to see that one person,
at least, thinks I am perfect.

>>>undefined behavior for out-of-bounds pointers,

The solution to that is easy. Keep your pointers under control.

So easy said but so difficult to do in practice Heathfield.

Why?

Let's take a BUG of yours then:

By all means. I'm always willing to learn.

In your book "C unleashed" you assume that sizeof(int) == sizeof(void *)
in page 352 and following. And you did not realize it till now maybe.

I'm looking at page 352. I can't see anywhere on that page where I assume
sizeof(int) == sizeof(void *). Please feel free to point it out.

I have the 2000 edition, maybe you did get a new one but in any case
that BIG BUG is in there, without any disclaimer Heathfield.

Which bug? I'm not seeing it. I'm not perfect, though, so perhaps I'm simply
overlooking it. Could you explain, please?

Please, do not assume that you are perfect.

I have never done so.

<snip>

>>>There'd
be no need for snprintf, strlcat, or garbage collection.

I have not yet seen a convincing argument that any of these is needed.
Certainly I've never needed them.

You do NOT need snprintf... nice.

Right.

How do you do snprintf then?

I don't. I don't need to. Didn't I just say that?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Nils O. Selåsdal]

jacob navia wrote:

Bill Pursell a écrit :

>jacob navia wrote:

>>MotoK a écrit :

I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

There is something much better:
a garbage collector.

Which doesn't exist in standard C. lcc-win32 may provide
one, but it isn't standard C and it's generally a bad idea
to rely on a GC. If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.)

Yes of course!

C is for "macho" programmers that drink beer and
are just backwards.

This is of course YOUR opinion. I beg to differ.

He didn't claim it was "macho". He simply said that C is likely
the wrong tool if you start desiring a garbage collector for
your programs. I agree with that, and it has nothing to do with
what you claim.

[CBFalconer]

Richard Heathfield wrote:

jacob navia said:

>Richard Heathfield wrote:

>>>

.... snip ...

>

>>>There'd be no need for snprintf, strlcat, or garbage collection.

I have not yet seen a convincing argument that any of these is
needed. Certainly I've never needed them.

You do NOT need snprintf... nice.

Right.

>How do you do snprintf then?

I don't. I don't need to. Didn't I just say that?

Once stdio provides putc and getc, nothing more is really needed
(apart from fopen, fclose, and the ilk). fflush is probably also
necessary. The rest is for convenience.

--
Some informative links:
news:news.announce.newusers
http://www.geocities.com/nnqweb/
http://www.catb.org/~esr/faqs/smart-questions.html
http://www.caliburn.nl/topposting.html
http://www.netmeister.org/news/learn2quote.html

--
Posted via a free Usenet account from http://www.teranews.com

[Ivanna Pee]

jacob navia wrote:

Bill Pursell a écrit :

jacob navia wrote:

>MotoK a écrit :

I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

There is something much better:
a garbage collector.

Which doesn't exist in standard C. lcc-win32 may provide
one, but it isn't standard C and it's generally a bad idea
to rely on a GC. If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.)

Yes of course!

C is for "macho" programmers that drink beer and
are just backwards.

This is of course YOUR opinion. I beg to differ.

The thing that takes
the place of a "smart pointer" in C is a "smart programmer".
You keep track of these things yourself.

Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

If we have computers is for THEM to do the mind numbing work,
not me. I do not try to outsmart a computer by
using MY brain to do THEIR work!

Hey, pretty soon you will be able to use the latest API call provided
in MFC :

void WinWriteMyProgramForMe(void);

This cutting edge technical stuff is right up your alley.

>Using a garbage collector obviates the need for smart pointers,
constructors, destructors, weird language constructs, etc etc.

A garbage collector *is* a "weird language construct".

Excuse me but you are dead wrong:

prototype:

void *GC_malloc(size_t);

usage:

char *buffer = GC_malloc(BUFSIZ);
WHAT is a "weird language construct" in there ???

The garbage collector imposes absolutely no
new language changes at all. You just use GC_malloc
instead of malloc, forget about free and link with
the provided library.

All this is 100% standard C.

>The most popular garbage collector is Boehm's one. Some compilers like
lcc-win32 provide a GC in the standard distribution. Other compilers
support it, notably GCC, and it can be used in any situation.

I'm not aware of gcc support for a garbage collector for C. It
supports
garbage collection for objective-C, but I don't believe it provides
it for C.

The garbage collector is "language agnostic" and will work for C,
C++ or objective C in the same fashion.

--
Bill Pursell

[Bill Pursell]

jacob navia wrote:

>
Saying that somebody that uses a GC should not program in C is
this "macho" attitude, that thinks that avoiding tools,
relying on the programmer never making an error, is THE
right way to develop software.

This attitude (only use malloc/free) closes itself to
technical improvements of the run time environment
without any reason or argument, "just because I never do any
mistakes"...

Let me clarify my position. I don't think that someone
who uses a GC shouldn't program in C. I do think that
someone shouldn't rely on a garbage collector
for the functions that they write in C. I use a garbage
collector often. And I program in C. I just don't mix
the two.

When I'm writing at a level for which a garbage collector
is appropriate, I use a language which is appropriate, and
it's not C.

--
Bill Pursell

[jacob navia]

Bill Pursell wrote:

jacob navia wrote:

>>Saying that somebody that uses a GC should not program in C is
this "macho" attitude, that thinks that avoiding tools,
relying on the programmer never making an error, is THE
right way to develop software.

This attitude (only use malloc/free) closes itself to
technical improvements of the run time environment
without any reason or argument, "just because I never do any
mistakes"...

Let me clarify my position. I don't think that someone
who uses a GC shouldn't program in C. I do think that
someone shouldn't rely on a garbage collector
for the functions that they write in C. I use a garbage
collector often. And I program in C. I just don't mix
the two.

When I'm writing at a level for which a garbage collector
is appropriate, I use a language which is appropriate, and
it's not C.

--
Bill Pursell

???
OK, your opinion.

I have written the debugger of lcc-win32 using the GC.
This has enormously simplified the debugger: I can allocate
a buffer anywhere in one of the threads of execution
and forget about it when I no longer need it.

A debugger needs to allocate displays build a lot of complicated
hierarchical data structures and throw them instantly away
when the program arrives somewhere else.

Using malloc/free this is an incredible difficult task. Each
buffer must be accounted for, each pointer that is cached somewhere must
be managed manually for validity, etc etc.

A GC allows you to forget about memory manager, and
concentrate in the task you are programming, in this case
the debugger.

The GC *simplifies* programming in C.

Using your logic I should have written a machine debugger in Java.

No.

C is the right language to write a C debugger. Using a GC it is
much easier, that's all.

Obviously you think that GC is for java/C#/lisp

Why not? I haven't anything against those languages. I am a different
opinion concerning the GC.

[Ancient_Hacker]

MotoK wrote:

Hi Experts,
I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

Regards
MotoK

IMHO you can't do that in C. C gives you complete freedom to make
copies of pointers, do pointer arithmetic, pass the address of a
pointer, call arbitrary functions written in bizarre languages--- all
things that will screw up smart pointers and garbage collection to a
fare-thee-well, or at least a seg fault.

What I do is write a logging malloc() and free() so at the end of the
program it can print out "37122 unfreed blocks using 293455128 bytes".
And then a list of file names and lines where those blocks were
malloc'ed.

[jacob navia]

Ancient_Hacker wrote:

MotoK wrote:

>>Hi Experts,
I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

Regards
MotoK

IMHO you can't do that in C. C gives you complete freedom to make
copies of pointers, do pointer arithmetic, pass the address of a
pointer, call arbitrary functions written in bizarre languages--- all
things that will screw up smart pointers and garbage collection to a
fare-thee-well, or at least a seg fault.

What I do is write a logging malloc() and free() so at the end of the
program it can print out "37122 unfreed blocks using 293455128 bytes".
And then a list of file names and lines where those blocks were
malloc'ed.

You are wrong what GC is concerned.
Normal C programs do not need a lot of care to use the GC,
and unless you explicitely hide the pointers from the GC
garbage collection will work perfectly with C.

[Keith Thompson]

jacob navia <ja***@jacob.remcomp.frwrites:
[...]

You are wrong what GC is concerned.
Normal C programs do not need a lot of care to use the GC,
and unless you explicitely

.... or implicitly ...

hide the pointers from the GC
garbage collection will work perfectly with C.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Tue, 12 Sep 2006 08:52:06 +0200, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:

>Bill Pursell a écrit :

>Which doesn't exist in standard C. lcc-win32 may provide
one, but it isn't standard C and it's generally a bad idea
to rely on a GC. If you are programming at a level where
you want a garbage collector, then you shouldn't be
programming in C. (My opinion.)

C is for "macho" programmers that drink beer and
are just backwards.

Thats not what he said, and as usual you post a silly reply which
serves no purpose except to damage the rest of your post and set
people against you.

>This is of course YOUR opinion. I beg to differ.

You could have posted this bit alone, and sounded rational instead of
stupid.

>Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

Statistically, you're 14% more likely to have an accident in bad
weather in an automatic*.

>I'm not aware of gcc support for a garbage collector for C. It
supports
garbage collection for objective-C, but I don't believe it provides
it for C.

The garbage collector is "language agnostic" and will work for C,
C++ or objective C in the same fashion.

I sincerely doubt this. Gathering garbage created by programmers
forgetting to delete objects or call destructors is somewhat different
to that created by programmers forgetting to call free, or pointing
pointers around randomly.

*or so a bloke in the pub told me. He's probably as reliable as
anyone.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[CBFalconer]

Mark McIntyre wrote:

<ja***@jacob.remcomp.frwrote:

.... snip ...

>

>Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

Statistically, you're 14% more likely to have an accident in bad
weather in an automatic*.

The next time you run out of fuel and stall on a railroad crossing,
and want to walk the car out of the way of the train with the
starter motor, please describe how you do that when equipped with a
slush box.

--
"I was born lazy. I am no lazier now than I was forty years
ago, but that is because I reached the limit forty years ago.
You can't go beyond possibility." -- Mark Twain

--
Posted via a free Usenet account from http://www.teranews.com

[Ian Collins]

CBFalconer wrote:

Mark McIntyre wrote:

>><ja***@jacob.remcomp.frwrote:

.... snip ...

>>>Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

Statistically, you're 14% more likely to have an accident in bad
weather in an automatic*.

The next time you run out of fuel and stall on a railroad crossing,
and want to walk the car out of the way of the train with the
starter motor, please describe how you do that when equipped with a
slush box.

slush box?

--
Ian Collins.

[Richard Heathfield]

CBFalconer said:

Mark McIntyre wrote:

><ja***@jacob.remcomp.frwrote:

... snip ...

>>

>>Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

Statistically, you're 14% more likely to have an accident in bad
weather in an automatic*.

The next time you run out of fuel and stall on a railroad crossing,

Having driven for a great many years, I am pleased to report that I have
never, ever run out of fuel. This is not mere luck. It is the result of
forethought.

Having driven for a great many years, I am pleased to report that I have
never, ever stalled on a level crossing. This is not mere luck. It is the
result of forethought.

The chance of my doing either of these is vanishingly small, and the chance
of doing both simultaneously is epsilon squared.

On the other hand, you wouldn't catch me driving an automatic, at least not
through choice.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[MotoK]

Hello All,
Well i got some inputs like GC and logging utility.Thanks to all.

[Spiros Bousbouras]

MotoK wrote:

Hello All,
Well i got some inputs like GC and logging utility.Thanks to all.

You are off topic. This is a thread about "slush boxes".

[jacob navia]

Richard Heathfield wrote:

>
On the other hand, you wouldn't catch me driving an automatic, at least not
through choice.

Ahhh OK. I understand now why you are against the GC.

I drive an automatic, relaxed, no effort, the machine works for
me, not the other way around...

jacob

[Richard Bos]

jacob navia <ja***@jacob.remcomp.frwrote:

Richard Heathfield wrote:

On the other hand, you wouldn't catch me driving an automatic, at least not
through choice.

Ahhh OK. I understand now why you are against the GC.

I drive an automatic, relaxed, no effort, the machine works for
me, not the other way around...

In short, you can't drive. That's no shame, many people can neither
drive nor program competently, and yet be valuable members of society;
but do not try to lecture to those of us who can.

Richard

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>>
On the other hand, you wouldn't catch me driving an automatic, at least
not through choice.

Ahhh OK. I understand now why you are against the GC.

What makes you think I'm against automatic garbage collection? What I'm
against is the claim that C provides it.

I drive an automatic, relaxed, no effort,

There's nothing particularly arduous about using a manual gearbox, and you
have more control over the machine. There's nothing particularly arduous
about managing memory, either. But if you don't want to do it, fine, use
automatic garbage collection by all means. I don't have a problem with
that. But C does not provide automatic garbage collection.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Chris Dollin]

jacob navia wrote:

I drive an automatic, relaxed, no effort, the machine works for
me, not the other way around...

Funny, works that way for me with a manual. (Automatics set my
teeth on edge when they persistently change gear at the wrong
time. I've learned to cope when in the US.)

This, of course, is why C programmers from the UK use the `auto`
keyword, because they're used to having to explicitly ask when
they need an automatic.

--
Chris "believe me at your peril" Dollin
A rock is not a fact. A rock is a rock.

[Ancient_Hacker]

jacob navia wrote:

You are wrong what GC is concerned.
Normal C programs do not need a lot of care to use the GC,
and unless you explicitely hide the pointers from the GC
garbage collection will work perfectly with C.

Please explain exactly how garbage collection can ever work with C in
these cases:

void RememberName( char * a, char * b, char * c ){ static char * aa, *
bb, * cc;
aa = a; bb = b; cc = c;
}
char * p1; char * p2; char * p3; struct goob { char * Hidden; } goo;

int main( void ) {
p1 = GetMeGarbageCollectedMemory( 1000 ); /* ask GC politely for some
memory */

p2 = p1; /* make a copy of the pointer, GC knows nothing about this
variable */

p3 = strdup( "foooooo" ); /* p3 is allocated from the heap, prolly
unknown to GC */
goo.Hidden = p1; /* field buried, prolly unknown to GC */
RememberName( p1, p2, p3 ); /* call some function that unknown to
anyone, makes static copies of the ptrs. */
return 0
}

Now please explain how the memory allocated for p1 gets preserved, or
collected, at the proper times, as the case may be. Hint: velly velly
difficult to impossible.

[jacob navia]

Ancient_Hacker wrote:

jacob navia wrote:

>>You are wrong what GC is concerned.
Normal C programs do not need a lot of care to use the GC,
and unless you explicitely hide the pointers from the GC
garbage collection will work perfectly with C.

Please explain exactly how garbage collection can ever work with C in
these cases:

void RememberName( char * a, char * b, char * c ){ static char * aa, *
bb, * cc;
aa = a; bb = b; cc = c;
}
char * p1; char * p2; char * p3; struct goob { char * Hidden; } goo;

int main( void ) {
p1 = GetMeGarbageCollectedMemory( 1000 ); /* ask GC politely for some
memory */

p2 = p1; /* make a copy of the pointer, GC knows nothing about this
variable */

p3 = strdup( "foooooo" ); /* p3 is allocated from the heap, prolly
unknown to GC */
goo.Hidden = p1; /* field buried, prolly unknown to GC */
RememberName( p1, p2, p3 ); /* call some function that unknown to
anyone, makes static copies of the ptrs. */
return 0
}

Now please explain how the memory allocated for p1 gets preserved, or
collected, at the proper times, as the case may be. Hint: velly velly
difficult to impossible.

This is peanuts for the GC.

1) ALL pointers stored in the data section of the executable (static
variables) are considered roots and they are followed.
2) In your example, p1, p2, p3 are all roots, and the memory they
use will be known to the GC.
3) all pointers to the heap point to memory NOT managed by the GC
so they are ignored. OBVIOUSLY it is a very bad idea to pass to
fre() a GC malloced pointer...

[jacob navia]

Richard Heathfield wrote:

jacob navia said:

>>Richard Heathfield wrote:

>>>On the other hand, you wouldn't catch me driving an automatic, at least
not through choice.

Ahhh OK. I understand now why you are against the GC.

What makes you think I'm against automatic garbage collection? What I'm
against is the claim that C provides it.

Never did such a claim. "ISO C" doesn't provide it, nor you will
find it in MSVC or other systems. You can use it with those systems
but it is (as I have explained zillion times) an ADD ON LIBRARY!!!
P.S. like smart pointers and C++. C++ does NOT provide "smart pointers".
They are add ons.

>

>>I drive an automatic, relaxed, no effort,

There's nothing particularly arduous about using a manual gearbox, and you
have more control over the machine. There's nothing particularly arduous
about managing memory, either. But if you don't want to do it, fine, use
automatic garbage collection by all means. I don't have a problem with
that. But C does not provide automatic garbage collection.

ISO C doesn't.

[Ian Collins]

jacob navia wrote:

Richard Heathfield wrote:

>jacob navia said:

>>Richard Heathfield wrote:

On the other hand, you wouldn't catch me driving an automatic, at least
not through choice.
Ahhh OK. I understand now why you are against the GC.

What makes you think I'm against automatic garbage collection? What
I'm against is the claim that C provides it.

Never did such a claim. "ISO C" doesn't provide it, nor you will
find it in MSVC or other systems. You can use it with those systems
but it is (as I have explained zillion times) an ADD ON LIBRARY!!!
P.S. like smart pointers and C++. C++ does NOT provide "smart pointers".
They are add ons.

Poor analogy, smart pointers can be implemented using any standard
conforming C++ compiler. They do not require any language extensions.

They can also make GC redundant, but that's another story for another
place.
--
Ian Collins.

[Rod Pemberton]

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...

No, your compiler system is not denigrated here. What is denigrated here

is

your apparent inability to separate the idea of "C" from the idea of
"lcc-win32". The distinction is an important one.

No. That idea is completely incorrect. You'll never find a post from Doug
Gwyn (comp.std.c, ANSI C X3J11 standard, developer of the Army's BRL-UNIX
in ANSI C) where his explanation doesn't take the underlying assembly,
physical hardware such as the cpu and memory into account.

This is what Larry Rosler (another contributor to ANSI C X3J11) says about
C:
"I taught the first course on C at Bell Labs, using a draft of K&R, which
helped vet the exercises. The students were hardware engineers who were
being induced to learn programming. They found C (which is 'portable
assembly language') much to their liking. Essentials such as pointers are
very clear if you have a machine model in mind."

C is built upon assembly. The abstraction of C from assembly (which you're
promoting) is the problem. It's why almost no one here understands what is
and isn't actually pointer in assembly... You need to learn assembly first
to truly understand C. I honestly doubt that any C programmer could write a
C compiler, even when given the additional advantage of using an existing C
compiler, without understanding assembly.
Rod Pemberton

[Richard Heathfield]

jacob navia said:

Richard Heathfield wrote:

>jacob navia said:

>>>Richard Heathfield wrote:

On the other hand, you wouldn't catch me driving an automatic, at least
not through choice.
Ahhh OK. I understand now why you are against the GC.

What makes you think I'm against automatic garbage collection? What I'm
against is the claim that C provides it.

Never did such a claim.

Extract from Message-ID: <45***********************@news.orange.fr>
(author: Jacob Navia)
-------------------------------------------------------------------

Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

Regards
MotoK

There is something much better:

a garbage collector.
-------------------------------------------------------------------

<snip>

>But C does not provide automatic garbage collection.

ISO C doesn't.

C is defined by ISO/IEC 9899 (and, for historical purposes, also by K&R1).
If by "ISO C", you mean the language defined by ISO/IEC 9899, then there is
no distinction between "C" and "ISO C", so you are now agreeing that C does
not provide automatic garbage collection.

It took you a while, but well done for finally working it out - if, indeed,
you have.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Richard Heathfield]

Rod Pemberton said:

>
"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...

>No, your compiler system is not denigrated here. What is denigrated here

is

>your apparent inability to separate the idea of "C" from the idea of
"lcc-win32". The distinction is an important one.

No. That idea is completely incorrect. You'll never find a post from
Doug
Gwyn (comp.std.c, ANSI C X3J11 standard, developer of the Army's BRL-UNIX
in ANSI C) where his explanation doesn't take the underlying assembly,
physical hardware such as the cpu and memory into account.

Yes, I know who Doug Gwyn is, and he is very much a respected, albeit
occasional, contributor to this newsgroup. I am very familiar with his
writing style. And I can say without a shadow of a doubt that you are
absolutely and utterly mistaken. Doug Gwyn has written a great many
articles that don't even mention the underlying assembly, physical hardware
such as the cpu, or memory (in the stuff-you-can-kick sense), let alone
"take them into account", so your claim that he never does so is quite
wrong.

Furthermore, I am quite sure Doug Gwyn would agree fully with me that the
distinction between "C" and "lcc-win32" is an important one. Why don't you
ask him?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Spiro Trikaliotis]

Hello,

I will not add any more to this discussion here, as I believe it is OT.

Anyway, just one hint:

Ancient_Hacker <gr**@comcast.netschrieb:

Please explain exactly how garbage collection can ever work with C in
these cases:

[...]

Now please explain how the memory allocated for p1 gets preserved, or
collected, at the proper times, as the case may be. Hint: velly velly
difficult to impossible.

I think this will work. lcc-win32 uses Boehm's garbage collector, cf.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Notice that this GC is "conservative", that is, it will not free memory
until it is absolutely sure that it is unused. When in doubt, it will
rather keep the memory, so it will not break anything.

This results in some "interesting" facts:

(From http://www.hpl.hp.com/personal/Hans_Boehm/gc/faq.html):

"Does this mean that the collector might leak memory?

In the short term yes. But it is unlikely, though not impossible, that
this will result in a leak that grows over time. Under normal
circumstances, short term, or one time leaks are a minor issue. Memory
leaks in explicitly managed programs are feared because they almost
always continue to grow over time.

[...]

If my heap uses 2 GB on a 32-bit machine, won't every other integer or
other random data be misinterpreted as a pointer by the collector?
Thus won't way too much memory be retained?

Maybe. Probably, if the collector is used purely conservatively, with
no pointer layout information (such as use of GC_MALLOC_ATOMIC)."

The most interesting part: This GC is not perfect (unlike Jacob wants us
make to believe), thus, chances are that you will end up with some
long-term memory leaks.

This website of Boehm is very interesting, and you can see the
advantages and the disadvantages of this GC; thus, you can decide if you
want to use it or not.

Anyway, as it clearly is not part of any "official" version of C (unlike
state by Jacob), I consider it off-topic. Thus, I will not answer on
this topic anymore here.

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

[Keith Thompson]

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...

>No, your compiler system is not denigrated here. What is denigrated
here is your apparent inability to separate the idea of "C" from
the idea of "lcc-win32". The distinction is an important one.

No. That idea is completely incorrect.

You're saying that the distinction between C and lcc-win32 is *not* an
important one? Fascinating.

You'll never find a post
from Doug Gwyn (comp.std.c, ANSI C X3J11 standard, developer of the
Army's BRL-UNIX in ANSI C) where his explanation doesn't take the
underlying assembly, physical hardware such as the cpu and memory
into account.

Nonsense.

[snip]

C is built upon assembly. The abstraction of C from assembly (which you're
promoting) is the problem. It's why almost no one here understands what is
and isn't actually pointer in assembly... You need to learn assembly first
to truly understand C. I honestly doubt that any C programmer could write a
C compiler, even when given the additional advantage of using an existing C
compiler, without understanding assembly.

More nonsense.

C, as defined by the ISO C standard, works on an "abstract machine".
It is not necessary to understand the underlying physical CPU to
understand how a portable C program works. Which is very fortunate,
because different hardware works differently; if C programmers
actually had to understand all possible hardware, there would be very
few C programmers.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[William Hughes]

Rod Pemberton wrote:

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...

No, your compiler system is not denigrated here. What is denigrated here

is

your apparent inability to separate the idea of "C" from the idea of
"lcc-win32". The distinction is an important one.

No. That idea is completely incorrect.

You seem to be saying that C and C compilers are the same thing,
or at least you can't really understand C without understanding
a C compiler. Many people would disagree.

>You'll never find a post from Doug
Gwyn (comp.std.c, ANSI C X3J11 standard, developer of the Army's BRL-UNIX
in ANSI C) where his explanation doesn't take the underlying assembly,
physical hardware such as the cpu and memory into account.

Untrue, and where it is true irrelevent. There are many aspects of
defining the C standard where it is crucial to consider the underlying
hardware.

This is what Larry Rosler (another contributor to ANSI C X3J11) says about
C:
"I taught the first course on C at Bell Labs, using a draft of K&R, which
helped vet the exercises. The students were hardware engineers who were
being induced to learn programming. They found C (which is 'portable
assembly language') much to their liking. Essentials such as pointers are
very clear if you have a machine model in mind."

Well, I don't know anyone who disagrees with this (knowing a machine
model helps in some ways to understand pointers), but Larry Rostler's
comment does not imply that you need to understand a machine model
to understand pointers. It does not deal with the question of whether
there are disadvantages as well as advantages to kowing a machine model
(the most obvious putative disadvantage is the tendency to believe
that pointers must behave
exatly like addresses on machine X)

C is built upon assembly. The abstraction of C from assembly (which you're
promoting) is the problem. It's why almost no one here understands what is
and isn't actually pointer in assembly...

There is no such thing as assembly, there are many. There is
no way to know " what is and isn't actually pointer in assembly".
On the other hand is is possible to know "
what is and isn't actually pointer in C.

You need to learn assembly first
to truly understand C. I honestly doubt that any C programmer could write a
C compiler, even when given the additional advantage of using an existing C
compiler, without understanding assembly.

[Trivialy untrue. Just copy the existing C compiler] So what. Most
people do not write compilers. The question
is, "Can a C programmer write a good C program without understanding
assembly?". I, and many others, would answer yes to that question.
-William Hughes

[Mark McIntyre]

On Tue, 12 Sep 2006 22:58:07 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:

>Mark McIntyre wrote:

><ja***@jacob.remcomp.frwrote:

... snip ...

>>

>>Look dear, I use an automatic drive, and do not care about
passing gears when driving you see?

Statistically, you're 14% more likely to have an accident in bad
weather in an automatic*.

The next time you run out of fuel and stall on a railroad crossing,
and want to walk the car out of the way of the train with the
starter motor, please describe how you do that when equipped with a
slush box.

I put mine into 4wd and use the starting handle...
:-)

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Wed, 13 Sep 2006 16:16:22 +1200, in comp.lang.c , Ian Collins
<ia******@hotmail.comwrote:

>slush box?

fluid flywheel, the device that automatics rely on to let you change
gear without scrunching all the little cog thingys.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Wed, 13 Sep 2006 06:12:49 +0000, in comp.lang.c , Richard
Heathfield <in*****@invalid.invalidwrote:

>Having driven for a great many years, I am pleased to report that I have
never, ever stalled on a level crossing. This is not mere luck. It is the
result of forethought.

Yeah, Dr Beeching's....

oof.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[websnarf]

Ancient_Hacker wrote:

MotoK wrote:

Hi Experts,
I've just joined this group and want to know something:
Is there something similar to smart pointers in C or something to
prevent memory leakages in C programs.

IMHO you can't do that in C. C gives you complete freedom to make
copies of pointers, do pointer arithmetic, pass the address of a
pointer, call arbitrary functions written in bizarre languages--- all
things that will screw up smart pointers and garbage collection to a
fare-thee-well, or at least a seg fault.

What I do is write a logging malloc() and free() so at the end of the
program it can print out "37122 unfreed blocks using 293455128 bytes".
And then a list of file names and lines where those blocks were
malloc'ed.

That's a good approach, which I've used myself. But you can do more --
detect double frees on the fly, as well as frees/reallocs to defective
pointers and take note of frees/reallocs of NULL.

In place of declarations and clearings you can create macros that
auto-initialize and set to NULL after free. For example, in Bstrlib I
give the following macros:

#define bstrDeclare(b) bstring (b) = NULL;
#define bstrFree(b) do {if ((b) != NULL && (b)->slen >= 0 && \
(b)->mlen >= (b)->slen) { bdestroy (b); (b) = NULL; }} while (0)

So in this way you can *envelope* a pointer so that under ordinary
circumstances its contents always reflect either legal or NULL
contents. Its a bit of a pain to do this for every data type, but
bstrings are a particularly good target since I used them as freely as
any other primitive data type, but they still carry with them all the
difficulties that come with pointers.

Its not quite "smart pointers" but in reality you end up close enough
that for practical purposes the differences don't much matter.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[websnarf]

Spiro Trikaliotis wrote:

Ancient_Hacker <gr**@comcast.netschrieb:

Please explain exactly how garbage collection can ever work with C in
these cases:

[...]

Now please explain how the memory allocated for p1 gets preserved, or
collected, at the proper times, as the case may be. Hint: velly velly
difficult to impossible.

I think this will work. lcc-win32 uses Boehm's garbage collector, cf.
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

[...]

The most interesting part: This GC is not perfect (unlike Jacob wants us
make to believe), thus, chances are that you will end up with some
long-term memory leaks.

First of all, that's not what it says. It says there are short term
leaks, or finite spillage long term. Neither of which are serious
issues in real world environments where leaks only threaten long term
running applications with an accumulating leak problem.

Second of all Boehm's GC mechanism is *portable* (in the sense that it
has been ported, like berkeley db) and solves the problem without
compile-time assistance. It is *possible* through Jacob's approach
(since he is maintaining both a compiler and a library) to use a lot of
compile-time assistance to greatly enhance the performance and accuracy
of a GC for C.

For example, at compile time you can determine that some locally scoped
pointers of a function never emit to values returned or to static
memory -- if so, the compiler can simply always use alloca() (allocate
off the stack) in place of malloc() when storing to those pointers.
Also, if the compiler can determine that the programmer within a
function has allocated then properly freed a pointer with no
possibility of leaking, it can switch to using a non-GC malloc (i.e.,
use memory that the GC will not try to analyze.)

This website of Boehm is very interesting, and you can see the
advantages and the disadvantages of this GC; thus, you can decide if you
want to use it or not.

Anyway, as it clearly is not part of any "official" version of C (unlike
state by Jacob), I consider it off-topic. Thus, I will not answer on
this topic anymore here.

Where do you suppose discussion of *implementation* of the C language
should be discussed? Keeping in mind that comp.compilers could care
less about std library implementations.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[Rod Pemberton]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...

No, your compiler system is not denigrated here. What is denigrated
here is your apparent inability to separate the idea of "C" from
the idea of "lcc-win32". The distinction is an important one.

No. That idea is completely incorrect.

You're saying that the distinction between C and lcc-win32 is *not* an
important one? Fascinating.

Really? You disagree with me here and then turn around and (indirectly)
agree with what I just said:
KTC, as defined by the ISO C standard, works on an "abstract machine".

But, of course, your IQ is high enough and your experience is deep enough
that you understood that you can't separate one from the other, didn't you?
Rod Pemberton

[Rod Pemberton]

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:VZ******************************@bt.com...

Rod Pemberton said:

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...

No, your compiler system is not denigrated here. What is denigrated

here

is

your apparent inability to separate the idea of "C" from the idea of
"lcc-win32". The distinction is an important one.

No. That idea is completely incorrect. You'll never find a post from
Doug
Gwyn (comp.std.c, ANSI C X3J11 standard, developer of the Army's

BRL-UNIX

in ANSI C) where his explanation doesn't take the underlying assembly,
physical hardware such as the cpu and memory into account.

Yes, I know who Doug Gwyn is, and he is very much a respected, albeit
occasional, contributor to this newsgroup. I am very familiar with his
writing style. And I can say without a shadow of a doubt that you are
absolutely and utterly mistaken. Doug Gwyn has written a great many
articles that don't even mention the underlying assembly, physical

hardware

such as the cpu, or memory (in the stuff-you-can-kick sense), let alone
"take them into account", so your claim that he never does so is quite
wrong.

You've misinterpreted this statement: "his explanation doesn't take the
underlying...into account" to mean that he _explicitly_ "mention(s) the
underlying assembly, physical hardware". That isn't even close to what I
said. He doesn't always explicitly mention them. But, his answers are
always worded to work properly with them. I've seen numerous laughable
answers from Plauger where he doesn't make sure that his answers comply with
assembly or hardware implementations.

What this also tells me is:
either A) you have little, if no, assembly experience
or B) if you do, you've failed to fully comprehend what you read
(which I think I had numerous prior complaints with you, didn't I?)

Furthermore, I am quite sure Doug Gwyn would agree fully with me that the
distinction between "C" and "lcc-win32" is an important one. Why don't you
ask him?

Read my reply to Keith on this same issue... You do agree with Keith, don't
you?
Rod Pemberton

[Richard Heathfield]

Rod Pemberton said:

>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Rod Pemberton" <do*********@bitfoad.cmmwrites:

"Richard Heathfield" <in*****@invalid.invalidwrote in message
news:B4******************************@bt.com...
No, your compiler system is not denigrated here. What is denigrated
here is your apparent inability to separate the idea of "C" from
the idea of "lcc-win32". The distinction is an important one.

No. That idea is completely incorrect.

You're saying that the distinction between C and lcc-win32 is *not* an
important one? Fascinating.

Really? You disagree with me here and then turn around and (indirectly)
agree with what I just said:
KTC, as defined by the ISO C standard, works on an "abstract machine".

strcmp("abstract machine", "lcc-win32") is not 0. Keith is not agreeing with
you either directly or indirectly.

<snip>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)