Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Strange C developments

Reply
Thread Tools

Strange C developments

 
 
John Bode
Guest
Posts: n/a
 
      07-23-2012
On Friday, July 20, 2012 4:14:50 PM UTC-5, Jase Schick wrote:
> Hi Can anyone explain why C has added support for pthreads, while NOT
> adding support for garbage collection? Convenient memory management would
> be a much greater enhancement than replicating a perfectly good existing
> library it seems to me.
>
> Jase


The main objection to automatic garbage collection in general that I've seen is its non-determinism, which can play hell in a realtime system. The general response to *that* is "when's the last time you had to work on a hardrealtime system, Jack?" (for me, the answer is "never").

Could be there was simply more demand from the C programming community for language-supported threading than for AGC.

Could also be that WG14 felt that the changes necessitated by threading were enough for one revision, or that the changes necessitated by GC would negatively impact legacy code or be too hard to implement with the current C architecture. I know that for myself, the behavior of malloc/realloc/calloc/free had damned well better not change *at all*; if you're going to add AGC, create a new library or add new functions to stdlib.

I haven't seen a C 2011 Rationale; would be nice to know what WG14 was thinking for this revision.

Seebs?
 
Reply With Quote
 
 
 
 
Philip Lantz
Guest
Posts: n/a
 
      07-24-2012
Ike Naar wrote:
> On 2012-07-22, BGB wrote:
> > or such...

>
> You keep on saying this. What does it mean?


To me, it means, "I don't really know what I'm talking about; you should
just ignore all the foregoing. In fact, to save time in the future, you
should probably just kill-file me."

I'm pretty sure that's not what BGB wants me to think, so I wish he
would stop saying it. I do still read his posts.
 
Reply With Quote
 
 
 
 
Philip Lantz
Guest
Posts: n/a
 
      07-24-2012
Gordon Burditt wrote:
> Do I have to set the pointer to NULL if it's stored in an auto
> variable (not in main()) and the ptr = NULL; statement would be
> immediately followed by a return statement?


Most likely in that case the compiler would know the variable is dead
and not actually store the NULL, so it wouldn't help the GC anyway
(unless there was some knowledge of the GC built into the compiler, but
I think the topic under discussion is the case where it isn't).

Any time registers containing pointers are saved in the stack, such as
before calling another function or in a function prologue, the GC has to
treat those pointers as live. Then when that stack area is reused for a
different stack frame, it is often not fully initialized, and the GC
will still see those pointers as live, even when they are just leftover
junk on the stack.

Whether or not this significantly limits the GC depends on the way the
code uses pointers.
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-24-2012
On Jul 21, 12:01*pm, jacob navia <(E-Mail Removed)> wrote:
> Le 21/07/12 12:23, Quentin Pope a ้crit :
>
>
>
>
>
> > On Sat, 21 Jul 2012 11:43:36 +0200, jacob navia wrote:
> >> Le 20/07/12 23:14, Jase Schick a ้crit :
> >>> Hi Can anyone explain why C has added support for pthreads, while NOT
> >>> adding support for garbage collection? Convenient memory management
> >>> would be a much greater enhancement than replicating a perfectly good
> >>> existing library it seems to me.

>
> >>> Jase

>
> >> The lcc-win compiler offers a garbage collector (Boehm's) in its
> >> standard distribution. It is a very useful feature, used for instance in
> >> the debugger of lcc-win, in the IDE and several other applications. Of
> >> course it is used by many of the people that have downloaded lcc-win
> >> (more than 1 million)

>
> > Do you never get tired of spamming this group with advertising for your
> > compiler?

>
> > Adding garbage collection would break a large amount of existing code.

>
> To port existing code to a GC environment you do not need to change a
> single line. Just define malloc as gc_malloc and define free as a noop.
>
> > Often the bottom couple of bits of pointers to memory with known
> > alignment properties will be used to store information (the pointer than
> > being and'd with ~0x3ul or similar prior to dereferencing).

>
> ??? That is not the case with the GC used by lcc-win.
>
> > Many code protection methods rely on storing pointers xor'd with an
> > obfuscating mask. GCs are not sophisticated enough to track such pointers.

>
> Yes, that kind of code shouldn't be used with a GC.
>
> > And what is the gain?

>
> The gain is that instead of loosing endless hours tracking that dangling
> pointer in the debugger you can concentrate on your application instead.
>
> > With careful programming, there is no need
> > whatsoever for this stupid overhead.

>
> You fail to mention "With careful programming and not making any
> mistake. NEVER. A single moment of inattention and you are screwed.
>
> Leave it for the kiddies programming
>
> > JAVA.

>
> JAVA, Lisp, C++, C, all the languages that can be used ith a collector.


JAVA and Lisp have to have GC. C++ and C may have a limited GC
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-24-2012
On Jul 21, 6:03*pm, jacob navia <(E-Mail Removed)> wrote:

> 2) In modern machines a collector slows down the program for at most
> a milisecond in normal situations, that could be bigger but not much
> bigger since the collector tries to spread out the GC time in each
> allocation.


whilst that's impressive even a milisecond might matter in some real
time systems
 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-24-2012
On Jul 24, 8:56*am, Philip Lantz <(E-Mail Removed)> wrote:
> Ike Naar wrote:
> > On 2012-07-22, BGB wrote:


[various allocations stratagies listed]

> > > or such...


"and so on" "or in a similar fashion"

> > You keep on saying this. What does it mean?

>
> To me, it means, "I don't really know what I'm talking about; you should
> just ignore all the foregoing. In fact, to save time in the future, you
> should probably just kill-file me."
>
> I'm pretty sure that's not what BGB wants me to think, so I wish he
> would stop saying it. I do still read his posts.


I thought his point was that different sorts of memory may need
different allocation strategies was pretty uncontroversial. Not sure
why it deserved the snotty response...

 
Reply With Quote
 
Nick Keighley
Guest
Posts: n/a
 
      07-24-2012
On Jul 22, 9:37*am, "io_x" <(E-Mail Removed)> wrote:
> "Tim Rentsch" <(E-Mail Removed)> ha scritto nel messaggionews:(E-Mail Removed)...
>
> > If you have a large program that extensively uses malloc() and
> > manual reclamation, it would be great to have it converted
> > to use GC and see what the performance is like. *I would love
> > to have a counter-point to offer to the GC fans.

>
> the conter-point is simply this: programmer has to think
> on memory of his/her program...
>
> > Of course,
> > if you do run some sort of comparison, it's important to try
> > to make it a fair comparison -- obviously the results can be
> > slanted one way or the other by choosing how one program is
> > transformed into the other.

>
> you can not compare what you control of what you not controll
> at all...
> if someone want to be a programer, he/she has to build his/her own
> malloc routines only for to have more
> controll hisself/herself program memory...
> so the way is opposite of use gc() etc...


nonsense
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      07-24-2012
ื‘ืชืืจื™ืš ื™ื•ื ืฉืœื™ืฉื™, 24 ื‘ื™ื•ืœื™ 2012 09:23:03 UTC+1, ืžืืช Nick Keighley:
> On Jul 21, 6:03ย*pm, jacob navia '(E-Mail Removed)' wrote:
>
> whilst that's impressive even a milisecond might matter in some real
> time systems
>

You've got twenty of them per frame in a 50 frames per second video system.So the garbage collector itself won't take down the system. However it's not a negligible consumer of resources.
 
Reply With Quote
 
BGB
Guest
Posts: n/a
 
      07-24-2012
On 7/24/2012 3:23 AM, Nick Keighley wrote:
> On Jul 21, 6:03 pm, jacob navia <(E-Mail Removed)> wrote:
>
>> 2) In modern machines a collector slows down the program for at most
>> a milisecond in normal situations, that could be bigger but not much
>> bigger since the collector tries to spread out the GC time in each
>> allocation.

>
> whilst that's impressive even a milisecond might matter in some real
> time systems
>


hard real-time, maybe.
then the usual strategy would be not to use a GC.
in any case, it would be best if C preserved the right to choice as to
whether or not GC is used.


soft real-time is, well, softer. typically, the matter of whether or not
a GC is used can be more left to the impact it may have on the user
experience. assuming that the GC is not running all the time (this is
likely only really in pathological conditions), the negative impact is
fairly small, but may allow delivering a better user experience overall
(while at the same time, preventing slower memory leaks from eventually
crashing the program).

speed critical code may also refrain from allocating memory or using
dynamic type-checking as well.


actually, as-is, GC libraries supply a choice as to whether or not GC is
used, apart from people arguing that "there is no choice, since they are
unusable".

any sort of standard GC would likely still need to preserve choice, and
hopefully not be too far in "lame duck" territory either.



decided to leave out anecdotes related to my experience plugging my GC
into the Quake 2 "hunk"-allocator system (basically, memory allocation
in a manner similar to a large stack).


 
Reply With Quote
 
Stefan Ram
Guest
Posts: n/a
 
      07-29-2012
"BartC" <(E-Mail Removed)> writes:
>C might well be faster - once you've finally finished and debugged the
>application.
>Meanwhile your competitor has had his application out for six months,
>because he's used a different approach. And he can upgrade his product more
>quickly.


And how do you explain the reports on TIOBE and other sites
according to which C has knocked GC-Java from its top position?

 
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
Spot Future Trends and Developments in the Recorded DVD & Video Market in the United Kingdom (Business Wire via Yahoo! Finance) admin@ng2000.com DVD Video 0 02-12-2007 08:02 AM
Quick survey on tools to increase quality in Java/J2EE developments & bet to win Champagne marc.rambert@gmail.com Java 0 03-15-2006 11:19 AM
(off topic) GOT-STL-P (Re: Interesting developments since "Beating the averages"?) alex.gman@gmail.com C++ 1 02-11-2006 05:10 PM
Some of the recent developments of the ISO C++ front Ioannis Vranos C++ 0 10-29-2004 09:14 PM
Interesting Blue-Ray developments poldy DVD Video 0 06-23-2004 03:52 AM



Advertisments