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

[Keith Thompson]

"Rod Pemberton" <do*********@bi tfoad.cmmwrites :

"Richard Heathfield" <in*****@invali d.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_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.

[William Hughes]

Rod Pemberton wrote:

"Richard Heathfield" <in*****@invali d.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********@yah oo.comwrote:

>Mark McIntyre wrote:

><ja***@jacob.r emcomp.frwrote:

... snip ...

>>

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

Statisticall y, 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******@hotma il.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*****@invali d.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.n etschrieb:

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.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...

"Rod Pemberton" <do*********@bi tfoad.cmmwrites :

"Richard Heathfield" <in*****@invali d.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*****@invali d.invalidwrote in message
news:VZ******** *************** *******@bt.com. ..

Rod Pemberton said:

"Richard Heathfield" <in*****@invali d.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...in to 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.orgw rote in message
news:ln******** ****@nuthaus.mi b.org...

>"Rod Pemberton" <do*********@bi tfoad.cmmwrites :

"Richard Heathfield" <in*****@invali d.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("abstrac t 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)