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,
constructor s, 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(BUFSI Z);
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**********@g mail.comwrote in message
news:11******** **************@ i42g2000cwa.goo glegroups.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.re mcomp.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_Keit h) 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**********@g mail.comwrote in message
news:11******** **************@ i42g2000cwa.goo glegroups.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**********@g mail.comwrote in message
news:11******** **************@ i42g2000cwa.goo glegroups.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