another bizarre architecture
in [Embedded]
|
From: Jan Panteltje on 1 Feb 2007 14:22 On a sunny day (Thu, 01 Feb 2007 19:02:07 GMT) it happened Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> wrote in <POqwh.15206$ji1.8499(a)newssvr12.news.prodigy.net>: > > >Jan Panteltje wrote: > > >> BOOL calculate_current(double resistance, double voltage, double *current) >> { >> if(debug) >> { >> fprintf(stderr,\ >> "calculate_current: arg resistance, voltage\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; >> } >> >> *current = voltage / resistance; >> >> if(debug) >> { >> fprintf(stderr, "calculate_current(): calculated current=%.2f\n", *current); >> } >> >> return OK >> } > >What a shamefull nonportable, unsafe and murky piece of code. You are naorrw minded. >This is a way to go: exit
From: John Devereux on 1 Feb 2007 14:27 Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> writes: > > What a shamefull nonportable, unsafe and murky piece of code. > > This is a way to go: > > CURRENT calculate_current(VOLTAGE voltage, RESISTANCE resistance) > { > CURRENT current; > > if(fabs(resistance) < VERY_SMALL_NUMBER) > { > throw BAD_RESISTANCE; > } > else > { > current = voltage/resistance; > } > return current; > } > Hey, that's C++! That's cheating! -- John Devereux
From: Jan Panteltje on 1 Feb 2007 14:37 On a sunny day (Thu, 01 Feb 2007 19:27:21 +0000) it happened John Devereux <jdREMOVE(a)THISdevereux.me.uk> wrote in <87irel3ch2.fsf(a)cordelia.devereux.me.uk>: >Vladimir Vassilevsky <antispam_bogus(a)hotmail.com> writes: > <snipped cheating code.> >Hey, that's C++! That's cheating! 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. 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. The good thing he did was check for divide by zero. So I should have written: BOOL calculate_current(double resistance, double voltage, double *current) { if(debug) { fprintf(stderr,\ "calculate_current: arg resistance, voltage\n",\ resistance, voltage); } /* avoid divide by zero */ if(resistance == 0.0) { fprintf(stderr,\ "calculate_current: resistance is zero, you have a super duper conductor,\n\ refer to sci.physics for help.\n"); return SUCKS; } 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; } *current = voltage / resistance; if(debug) { fprintf(stderr, "calculate_current(): calculated current=%.2f\n", *current); } return OK } hehe
From: Vladimir Vassilevsky on 1 Feb 2007 16:24 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 !=. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com
From: Vladimir Vassilevsky on 1 Feb 2007 18:01
John Larkin 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. No wonder. It is a tiny project for one man, where everything can be polished to perfection or at least kept under control. It will take me more calendar time, 2x > maybe, because I do other things, like design hardware and run a > company. I do maybe 4 such projects a year. > I think one reason I finish software quickly, and spend very little > time debugging, is because I don't really like to program, and as soon > as it's done (and tested, and released) I can do stuff that's more > fun. If I were a "programmer" I'd be looking to a future of nothing > but programming, so my incentive to finish is reduced (I'd never > "finish" programming) and the desire to play with clever > resume-padding "productivity" tools (abstraction, C++, OOP, Java, > whatever) would be a lot stronger. > One of my customers makes megabuck analytical instruments and the > programming staff has fallen in love with Java and abstraction from > the hardware. They're averaging about 6-8 bug announcements per week > and it's "spinning out of control." The abstraction and the object oriented tools are the necessity. The common software developers are the bunch of donkeys with the incredible ability to screw up anything. However, forcing the bunch into a simple, sensible and formal development framework allows you to make use of them. Vladimir Vassilevsky DSP and Mixed Signal Design Consultant http://www.abvolt.com |