Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Smart Pointers: Is there something similar to smart pointers in C?

Reply
Thread Tools

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

 
 
jacob navia
Guest
Posts: n/a
 
      09-12-2006
Martin Ambuhl wrote:
> 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.


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
 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      09-12-2006
Richard Heathfield wrote:
> Rod Pemberton said:
>
>
>>"Bill Pursell" <(E-Mail Removed)> wrote in message
>>news:(E-Mail Removed) groups.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.
>


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!!!
>
>>needing restrict pointers,

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

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


You never use ptrdiff_t, never forget anything when using free()
yes, YOU are perfect Heathfield, I am not.


>
>>undefined behavior for out-of-bounds pointers,

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

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


You do NOT need snprintf... nice. How do you do snprintf then?

(just curious)



> <snip>
>

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      09-12-2006
jacob navia said:

<snip>

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


Not for everybody.

<snip>

> 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
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      09-12-2006
jacob navia said:

> Richard Heathfield wrote:
>> [...] 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.

>>
>>>needing restrict pointers,

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


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?

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

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

>>>undefined behavior for out-of-bounds pointers,

>>
>> The solution to that is easy. Keep your pointers under control.

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

<snip>

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

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

--
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)
 
Reply With Quote
 
=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=
Guest
Posts: n/a
 
      09-12-2006
jacob navia wrote:
> 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.
>

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.

 
Reply With Quote
 
CBFalconer
Guest
Posts: n/a
 
      09-12-2006
Richard Heathfield wrote:
> jacob navia said:
>> Richard Heathfield wrote:
>>>

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

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


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:
news:news.announce.newusers
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



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
Ivanna Pee
Guest
Posts: n/a
 
      09-12-2006

jacob navia wrote:
> 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!


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.

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

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


 
Reply With Quote
 
Bill Pursell
Guest
Posts: n/a
 
      09-12-2006

jacob navia wrote:

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

--
Bill Pursell

 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      09-12-2006
Bill Pursell wrote:
> jacob navia wrote:
>
>
>>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.
>
> --
> Bill Pursell
>


???
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.
 
Reply With Quote
 
Ancient_Hacker
Guest
Posts: n/a
 
      09-12-2006

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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Is there something similar to list comprehension in dict? Peng Yu Python 8 11-20-2009 08:37 PM
Re: Is there something similar to list comprehension in dict? Patrick Sabin Python 1 11-20-2009 09:29 AM
Ambiguity with Smart Pointers (Boost or similar) number774@netscape.net C++ 6 01-03-2008 05:30 PM
Is there a goto statement (or something similar)? Mike42 Java 21 11-14-2005 12:22 PM
Is there something similar to ?: operator (C/C++) in Python? Bo Peng Python 31 06-30-2005 06:19 PM



Advertisments