another bizarre architecture
in [Embedded]
|
From: jasen on 2 Feb 2007 14:02 On 2007-02-01, Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> wrote: > > > Jan Panteltje wrote: > >>>Hey, that's C++! That's cheating! > > There is only one language: C++. The so called C is the malformed > realization of C++, where you have to do classes by hand. > >> >> Yea and it sucks, because 'throw' is not in libc in C. >> And throwing an exeption may not always be what you want, expensive missiles >> have unexpectedly returned to earth that way. > > It is better to stay on the earth rather then fall on somebody's head. > Masking the errors is the worst practice. > >> Maybe a if a malloc() fails, and continuing has no perspective, >> but just as well you could in this case return to a GUI that asks for >> a correct user input, so returns SUCKS or return OK, report in the function >> itself, and determine in the calling what to do if it sucks. > > Come on, get real. Nobody bothers about checking the return value. > >> The good thing he did was check for divide by zero. > > Only the amateurs check the floating point for == or !=. divide by a too-small or zero and you'll get some sort of infinite or not-a-number from the divide, so, just divide and check the result using isfinite or isnormal(). depending on the result you're expecting. Bye. Jasen
From: Paul Keinanen on 2 Feb 2007 16:17 On Fri, 02 Feb 2007 12:26:59 -0800, John Larkin <jjlarkin(a)highNOTlandTHIStechnologyPART.com> wrote: >But it's seldom the CPU or the memory that fails; Hardware will fail quite often due to radiation, EMC problems, UPS failure or simply capacitor "rot". >it's the software itself. I try to write my software so that it wont't fail until I am retired. >Memories don't leak, but memory allocators/deallocators do. You have memory leak problems only if you use deallocators :-). A program can use allocators at startup, but should avoid them during the next decades the program is running. Paul
From: CBFalconer on 2 Feb 2007 14:56 Jan Panteltje wrote: > .... snip ... > > if(resistance < 0.0) > { > fprintf(stderr,\ > "My-Program: calculate_current():\n\ > Your resistance is negative (%.2f), you must be kidding right? Aborting.\n",\ > resistance); > > return SUCKS; > } There is no need to use those continuation lines, which just distort your code. A '\n' is just another whitespace char. to a C compiler. In addition strings separated by only whitespace are automatically concatenated. You can be much clearer with: BOOL calculate_current(double resistance, double voltage, double *current) { if (debug) { fprintf(stderr, "calculate_current: %f %f\n", resistance, voltage); } if (resistance < 0.0) { fprintf(stderr, "My-Program: calculate_current():\n" "Your resistance is negative (%.2f)," " you must be kidding right? Aborting.\n",\ resistance); return SUCKS; } else /* whatever */; } Note how I try to associate a format specifier with the appropriate object. By the way, negative resistance normally implies an amplifier. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: CBFalconer on 2 Feb 2007 14:59 John Devereux wrote: > .... snip ... > > Of course I comment the source code - I was just making the point > that you don't always want some "version" number written as a > comment in the C source file. There can be better ways to handle > revision control than typing a number into each source file. Look at the documentation for your version control system. There is almost certainly a way of automatically updating a version comment when the source is checked in. No pain whatsoever. -- <http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt> "A man who is right every time is not likely to do very much." -- Francis Crick, co-discover of DNA "There is nothing more amazing than stupidity in action." -- Thomas Matthews
From: Paul Taylor on 2 Feb 2007 16:28
On Fri, 02 Feb 2007 15:48:15 +0000, Robert Latest wrote: >> I'll typically spend about 1-2 man-weeks on an embedded product >> program, generally around 4-6 klines of code, from start to formal >> release of bug-free code. That is a lot of code for a short amount of time .... I'm starting to get an inferiority complex. Bug free as well ??? > But these are very small projects, in softwareterms. Any half-decent > programmer can do that, no matter in what language. Right, that's it, I'm out of here ;-) Regards, Paul. |