API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: Richard Heathfield on 21 Dec 2009 04:11 In <7p8914F9phU1(a)mid.individual.net>, Ian Collins wrote: <snip> > But ["grabage [sic] collection"] isn't practical on > the majority of platforms C is used on these days. That's irrelevant to Jacob Navia. He's scratching an itch, which is a perfectly respectable thing for a programmer to do. And if he wrongly assumes that everyone else has the same itch, he's hardly unique in that, is he? -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Ian Collins on 21 Dec 2009 04:09 jacob navia wrote: > Ian Collins a écrit : >> Where's the quotes I asked for? >> FACT: The majority of new C development is for embedded applications > > All new development done for the linux kernel and the thousands > of C systems in linux/Mac/Windows do not count. Sure they do, but they'll be outnumbered by other embedded developments. > Your "Facts" aren't facts but assumptions of Mr Collins. > > And, by the way, if you are developing for an embedded processor, it is > probably better to use a GC and waste developper's time and risk bugs > with manual GC (malloc/free). For a lot of embedded targets (those with limited resources i.e most 8 and 16 bit machines), the best approach is a static design. > Today's embedded processors are huge machines by yesterday's standards. Some yes, but I don't think you appreciate how many small (8 and 16bit) embedded processors are still in use in new products today. > Only if you have real time requirements GC could be a problem. Or limited resources, or no operating system! > Only in 16 bits processors with a few kbytes of RAM you could be right. There's an awful lot of those in use today, you'll have several in your PC and probably several dozen in your home. > And so what? > > You *can* use a GC in many OTHER applications. Did I say you couldn't? -- Ian Collins
From: Flash Gordon on 21 Dec 2009 04:33 jacob navia wrote: > Ian Collins a écrit : >> >> FACT: The majority of new C development is for embedded applications > > All new development done for the linux kernel and the thousands > of C systems in linux/Mac/Windows do not count. Where did he say they don't count? I think that every new piece of hardware for a PC requiring a driver has at least one embedded processor, and probably a lot more code than the sum of the drivers for all the OSs for that HW. Then there is the software in all the embedded processors in TVs, Radios, cars, airplanes, MP3 players, DVD players, amplifiers, cookers... > Your "Facts" aren't facts but assumptions of Mr Collins. Not facts without proof, but quite likely. > And, by the way, if you are developing for an embedded processor, it is > probably better to use a GC and waste developper's time and risk bugs > with manual GC (malloc/free). In many applications you have hard real time requirements, so you can't afford things which might take an unknown amount of time, which includes malloc and free as well as GC. > Today's embedded processors are huge machines > by yesterday's standards. How big is the embedded processor in your phone? How about the one in your watch? > Only if you have real time requirements > GC could be a problem. Not only then. I've often had to need to know the upper bound of memory which will be used, and using GC makes that harder and potentially increases the figure (the memory may not be freed for some time after the last pointer is destroyed). > Analog Devices processors and DSP for example > are all 32 bits now. There is plenty of stuff other than DSPs. In fact, signal processing is something where you can need a lot of processing power but not necessarily much memory. Also a lot of signal processing you know exactly how much memory you need and don't need *any* dynamic allocation. > Only in 16 bits processors with a few kbytes of RAM you could be right. > > And so what? > > You *can* use a GC in many OTHER applications. Yes, and a lot of people do. However adding it to the C standard without buggering things up for the applications which cannot afford it is not easy. -- Flash Gordon
From: gwowen on 21 Dec 2009 07:11 On Dec 21, 8:51 am, jacob navia <ja...(a)nospam.org> wrote: > And, by the way, if you are developing for an embedded processor, it is > probably better to use a GC and waste developper's time and risk bugs > with manual GC (malloc/free). No. No it isn't. Unless you've got a relatively powerful embedded processor, like an ARM9, its frequently best not to use the heap at all. > Today's embedded processors are huge machines by yesterday's standards. Sure, some of them are. But the fact remains that tiny embedded processors are still produced in enormous numbers, because they're cheap. TI sell 16bit chips with 1kb of flash and 128bits of memory for 50 cents. For 4 or 5 dollars, you can get a full 16kb of RAM. Good luck running a garbage collector on that.
From: jacob navia on 21 Dec 2009 07:51
gwowen a �crit : > >> Today's embedded processors are huge machines by yesterday's standards. > > Sure, some of them are. But the fact remains that tiny embedded > processors are still produced in enormous numbers, because they're > cheap. TI sell 16bit chips with 1kb of flash and 128bits of memory for > 50 cents. For 4 or 5 dollars, you can get a full 16kb of RAM. Good > luck running a garbage collector on that. Sure, you have 16 BYTES of memory and you want C to run in that? Sorry but that is completely out of the question. |