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

[Richard Bos]

jacob navia <ja***@jacob.re mcomp.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

[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 = GetMeGarbageCol lectedMemory( 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 = GetMeGarbageCol lectedMemory( 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*****@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.

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************ ***********@new s.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*****@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.

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

Notice that this GC is "conservati ve", 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 "interestin g" 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_ATOMI C)."

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/