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

[jacob navia]

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]

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

 

[Mark McIntyre]

Bill Pursell a écrit :

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

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]

.... snip ...


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.

 

[Ian Collins]

.... snip ...



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?

 

[Richard Heathfield]

CBFalconer said:

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.

 

[MotoK]

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

 

[Spiros Bousbouras]

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]

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]

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:

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.

 

[Chris Dollin]

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.

 

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

jacob navia wrote:





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]

jacob navia said:




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.

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.

 

[Rod Pemberton]

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

 

[Ian Collins]

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.

 

[Richard Heathfield]

jacob navia said:

Never did such a claim.

Extract from Message-ID: <[email protected]>
(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.
-------------------------------------------------------------------

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]

Rod Pemberton said:

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?

 

[Spiro Trikaliotis]

Hello,

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

Anyway, just one hint:

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.