From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,INVALID_DATE, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,791ecb084fdaba75 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-05 13:10:34 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!newsxfer.itd.umich.edu!ncar!csn!boulder!news.coop.net!news.den.mmc.com!iplmail.orl.mmc.com!alcyone!rgilbert From: rgilbert@orl.mmc.com (Bob Gilbert) Newsgroups: comp.lang.ada Subject: Re: Types with physical dimension Date: 5 Oct 1994 14:53:09 GMT Organization: Martin Marietta Orlando Distribution: world Message-ID: <36uekl$cqq@theopolis.orl.mmc.com> References: <36rqfc$km7@gnat.cs.nyu.edu> Reply-To: rgilbert@orl.mmc.com NNTP-Posting-Host: alcyone.orl.mmc.com Date: 1994-10-05T14:53:09+00:00 List-Id: In article km7@gnat.cs.nyu.edu, dewar@cs.nyu.edu (Robert Dewar) writes: ->strong typing is like anything else, fine in moderation, but dangerous to ->health if overdoses are encountered. -> ->there is a common tendency in Ada programming to assume that since strong ->typing is a GOOD THING, it must make sense to use it as much as possible. ->This leads to programs which thousands of different integer types and ->conversions all over the place. For my taste that actually decreases ->reliability, since {good stuff deleted} I can't agree more with this. I my work, I deal with mostly embedded processors with lots of interfaces to hardware. I have found that a very common mistake is to over-type, especially on input data from less than reliable sources. As an example, we had an interface with an IRIG time code generator which was supposed to generate a BCD format of the time. One of our programmers quickly set out to generate a BCD type to accomodate the input. Unfortunately, hardward does not always behave itself, and on occasion the time code generator would lock up and produce an output of all one's. Well needless to say we got constraint exceptions like crazy, and being a real-time system we could not tolerate the indeterminate nature of exceptions (besides software always has the burden of proving the hardware went south, and we needed to know what the illegal values being sent to us were in order to provide the necessary evidence). The solution was to just accept the BCD time value as an array of bytes, and then perform explicit conversion of this array to either a string value for output to a terminal, or a numeric value for use in internal computations. The explicit routines to perform the conversions would handle the case where illegal inputs were received without the use of exception handling. Anyway, I have found it very useful to never place constaints on input data from outside sources, and explicitly check the data for correctness. Now output data is a different matter. If I am generating something like gimbal commands where hardware could possibly be damaged if I output invalid or out of range values, then I definitely use strong typing to guarantee my output. Here getting the rare exception is usually much preferred, people get very upset when we software types break hardware. And of course the exception is rare since I (sould) have control of the data. I'm also usually very leery when constraint limits are placed on floats. I've seen too many instances where a programmer generated something like a float to represent a value from say 0..360 degrees on a circle and found that some intermediate result would take the value outside the range, or possibly rounding effects gave a value of 360.00000001, or the like. Many times it is easier to track down the error if you have the incorrect result rather than just an exception at the point where the value went out of the type range. -Bob