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]

MotoK a écrit :

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.

 

[jacob navia]

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.)

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!

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.

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.

 

[Rod Pemberton]

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]

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]

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.

 

[Richard Heathfield]

jacob navia said:

MotoK a écrit :

There is something much better:

a garbage collector.

Wrong again. C provides no such thing.

 

[Richard Heathfield]

Rod Pemberton said:

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>

 

[jacob navia]

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]

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.



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]

Rod Pemberton said:




Feel free.




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!!!

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

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




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.

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.

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.





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)

 

[Richard Heathfield]

jacob navia said:

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

Not for everybody.

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]

jacob navia said:

[...] 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.

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?

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.

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.

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?

 

[=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=]

Bill Pursell a écrit :

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]

jacob navia said: .... snip ...


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:
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

 

[Ivanna Pee]

Bill Pursell a écrit :

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.


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.

 

[Bill Pursell]

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.

 

[jacob navia]

jacob navia wrote:




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.

???
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]

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.