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=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,751584f55705ddb7 X-Google-Attributes: gid103376,public From: eachus@spectre.mitre.org (Robert I. Eachus) Subject: Re: Ada is almost useless in embedded systems Date: 1996/03/15 Message-ID: #1/1 X-Deja-AN: 142914245 references: <823906039.22113@assen.demon.co.uk> organization: The Mitre Corp., Bedford, MA. newsgroups: comp.lang.ada Date: 1996-03-15T00:00:00+00:00 List-Id: In article bill.williams@gecm.com writes: > When you're inspecting someone elses code I like the shortcuts that the > rich C operators give you. My favourite example has got to be the > assignment operators, += etc. Take this (contrived) case... > How much easier to *require* (by means of coding standards etc.) the > first to be written > bibble_bobble.wibble_wobble += 3;... > And what if the coder had actually meant > OK, these names are clearly fatuous. But similar cases *do* arise in > complex software where, for perfectly sensible reasons a coding standard > requires all variables and structure members to have 'meaningful' names. > I don't think Ada is immune to this sort of problem. No, but the differnce is cultural, not linguistic. There have been programs where I needed to do lots of incrementing and declared: procedure Inc(X: in out Integer; Y: in Integer := 1) is begin X := X + Y; end Inc; pragma Inline(Inc); ...and then went and used it all over. I even had one program that provided half a dozen similar operations, and instantiated it for several integer types. Note that I COULD have written things in terms of the 'SUCC attribute, but the Ada cultural convention seems to be to only use 'SUCC and 'PRED for enumeration types, or generic formal enumeration types. > > (6) Strong Typing: In the Ada code, the type casting is and must > > be explicity coded. This provides secure compile-time > > documentation of how big each integer is at each step. This > > is especially useful when you are doing something tricky, > > like writing over memory in a segment register. > I approve of strong type *checking*. As we all know (except those > who either never write any 'difficult' apps. or never test what > they write) type mismatches are a major cause of errors. What > irritates me about Ada (and Eiffel is even worse!) is that when *I > know* that what I am doing is desirable and correct the language > won't let me produce a concise and easily readable expression of > it. And, no, I don't consider having to declare my conversion > routines in one part of a program so I can use them elsewhere a > particularly neat way of solving the problem. Ada deliberately > makes it 'unpleasant' to do an unchecked_conversion. IMO it goes a > bit too far. Ah, but in Ada CHECKED conversions are easy to write and don't require declarations. In Ada "X := Float(Y);" does just what you would expect, convert Y to Float and assign it to X. It is defined for Y of any numeric type. In fact, when you declare any numeric type you also implicitly create such a conversion operation. You also get well defined conversion operations with derived type declarations, and with many array declarations. It is only where you need to convert between types with no obvious mapping, or when you specifically want no checking, that you have to resort to Unchecked_Conversion. Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is... -- Robert I. Eachus with Standard_Disclaimer; use Standard_Disclaimer; function Message (Text: in Clever_Ideas) return Better_Ideas is...