API Design
in [General Programming]
|
Prev: Water plant design | Design Build | Water plant construction
Next: Two programs with same logic
From: gwowen on 21 Dec 2009 08:22 On Dec 21, 12:51 pm, jacob navia <ja...(a)nospam.org> wrote: > Sure, you have 16 BYTES of memory and you want C to run in that? > Sorry but that is completely out of the question. Of course it isn't. You can run C program code from the 1kb of flash. The volatile RAM is only needed for data.
From: Marco on 21 Dec 2009 10:25 On Dec 20, 4:42 pm, jacob navia <ja...(a)nospam.org> wrote: > Stefan Ram a écrit : > > > > > Nobody <nob...(a)nowhere.com> writes: > >> The situation is different for a long-lived process (i.e. interactive > >> application, daemon, etc), where even a small leak can eventually grow to > >> dominate memory consumption (although you also have to worry about heap > >> fragmentation in that situation). > > > Or for code in a library, when it is unknown, which kind of > > process will use it. Since the subject of this thread is > > »API Design«, this might be relevant here. > > > Some of you will already know the following quotations, > > because I have already posted them into Usenet before. > > > »There were two versions of it, one in Lisp and one in > > C++. The display subsystem of the Lisp version was faster. > > There were various reasons, but an important one was GC: > > the C++ code copied a lot of buffers because they got > > passed around in fairly complex ways, so it could be quite > > difficult to know when one could be deallocated. To avoid > > that problem, the C++ programmers just copied. The Lisp > > was GCed, so the Lisp programmers never had to worry about > > it; they just passed the buffers around, which reduced > > both memory use and CPU cycles spent copying.« > > The lcc-win compiler system provides a garbage collector in its standard > distribution. I respectfully disagree that this belongs in the C language. The C language is essentially portable assembly language and should remain that way. Of course JVMs and so forth are usually written in C. I don't want featuritis in the C language. Jacob please create a new language if needed. Of course, anybody can create C API libraries for others to use with as many features as you desire.
From: jacob navia on 21 Dec 2009 10:47 Marco a �crit : > > I respectfully disagree that this belongs in the C language. The C > language is essentially portable assembly language and should remain > that way. Of course JVMs and so forth are usually written in C. I > don't want featuritis in the C language. Jacob please create a new > language if needed. > After saying this, you go on saying: > Of course, anybody can create C API libraries for others to use with > as many features as you desire. Well, the GC is exactly that. Absolutely NO changes in the language are needed at all! Instead of callinc malloc(56) you call gc_malloc(56). And the good side is that instead of calling free() you do not call anything. This is in NO WAY a language change! How do you arrive at that idea? It is just an API.
From: BGB / cr88192 on 21 Dec 2009 13:05 "Ian Collins" <ian-news(a)hotmail.com> wrote in message news:7p8sacFp4lU3(a)mid.individual.net... > 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. > FWIW, Quake 1 / 2 / 3 were in C. Doom 3, maybe C, but I haven't seen the source (the scripts though have more of an OO style, so possibly C++ may have been used in Doom 3...). I also develop (mostly) in C, and generally write stuff which works on plain old computers... my reasons for using C are varried, although, part of it may be that most of the code I write is library code (mostly for my own uses), and also I use some amount of "reflection", which does not work so well with C++ (mostly giving the non-standardized name mangling and compiler behaviors, ...). similarly, the majority of code I end up encountering on the internet tends to be in C (even despite the levels of hype and seeming popularity of Java...). Java is one of those languages: one hears about it enough, but where is the code?... >> 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. > granted, but I still suspect "most of us" don't develop for embedded systems of this sort... for example, I suspect most developers probably still target actual computers, and C is not exactly an unheard of language for usage in typical computer-based apps... >> 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. > probably more are 32-bits though I think. >> Only if you have real time requirements GC could be a problem. > > Or limited resources, or no operating system! > the original PDP's were not exactly overflowing with RAM, and this is where GC got started... GC need not necessarily mean big memory... it may depend some though on how one defines and implements said GC though, as some strategies make more sense than others. >> 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. > I think the bus controllers contain one of these, mostly as I guess I read somewhere that some amount of the legacy hardware tends to be emulated (via SW running in the bus controller). >> 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 15:10
BGB / cr88192 wrote: > "Ian Collins" <ian-news(a)hotmail.com> wrote in message > news:7p8sacFp4lU3(a)mid.individual.net... >> 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. > > FWIW, Quake 1 / 2 / 3 were in C. > > Doom 3, maybe C, but I haven't seen the source (the scripts though have more > of an OO style, so possibly C++ may have been used in Doom 3...). > > I also develop (mostly) in C, and generally write stuff which works on plain > old computers... There is a lot still done in C... > my reasons for using C are varried, although, part of it may be that most of > the code I write is library code (mostly for my own uses), and also I use > some amount of "reflection", which does not work so well with C++ (mostly > giving the non-standardized name mangling and compiler behaviors, ...). Probably especially libraries and code for compilers. > similarly, the majority of code I end up encountering on the internet tends > to be in C (even despite the levels of hype and seeming popularity of > Java...). I don't think what you see on the internet is necessarily representative. There are some commercial areas where other languages have traditionally been used, and last time I was looking for a non-embedded SW development job most of the advertised jobs were not for C. > Java is one of those languages: > one hears about it enough, but where is the code?... We have a fair bit which we sell. >>> 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. > > granted, but I still suspect "most of us" don't develop for embedded systems > of this sort... Maybe most of the people you know, but who do you think is writing all of the code for all of the embedded systems, such as the several embedded systems in your desktop PC? It's us SW developers, that's who. > for example, I suspect most developers probably still target actual > computers, and C is not exactly an unheard of language for usage in typical > computer-based apps... It's not unheard of, but neither is Cobol (and I know there is still Cobal code out there in real current commercial applications being actively developed and sold). I'm sure that Fortran is still in serious use too if you know where to look. I also know of significant bodies of commercial Java code, and I've used open source applications developed in C#. As an example of the type of thing Java is used for, I know that several commercial applications use Apache Tomcat to provide web services, with the application code written in Java running under Tomcat (which is written in Java). >>> 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. > > probably more are 32-bits though I think. I have no evidence, but I would be surprised. I would be surprised if most of the processors in your car were not comparatively slow 8 and 16 bit processors, I know there are still a lot of such processors in use in military hardware (slow simple processors tend to cope with electrical noise better). I'll bet all of your remote controls have 8 bit (or smaller) processors since they don't need any more! >>> Only if you have real time requirements GC could be a problem. >> Or limited resources, or no operating system! > > the original PDP's were not exactly overflowing with RAM, and this is where > GC got started... > > GC need not necessarily mean big memory... Limited resource does not necessarily mean limited RAM. It could be limited code space, or limited time, or limited power (so wanting the processor to be idle)... > it may depend some though on how one defines and implements said GC though, > as some strategies make more sense than others. Obviously that makes a difference, and strategies will have improved over the years. >>> 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. > > I think the bus controllers contain one of these, mostly as I guess I read > somewhere that some amount of the legacy hardware tends to be emulated (via > SW running in the bus controller). <snip> How about the processor in the keyboard? Or the processor in the NIC? The processor in the USB controller? The processor in the embedded USB hub? A number of these won't be emulated in the bus controller simply because it is cheaper to use the same components that are used in the cards you can plug in to your PC (or in the case of the keyboard because it is at the far end of a piece of wire). Oh, and a lot of the time you have processors embedded in to ICs, there is a whole market in processor designs for programming in to the various forms of programmable logic devices. -- Flash Gordon |