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.1 required=5.0 tests=BAYES_05,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 109fba,1042f393323e22da X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public X-Google-Thread: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public From: Steve Jones - JON Subject: Re: Any research putting c above ada? Date: 1997/04/14 Message-ID: <2sybamvslk.fsf@hpodid2.eurocontrol.fr>#1/1 X-Deja-AN: 234675015 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> Organization: Eurocontrol Experimental Centre, Bretigny-Sur-Orge, France Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-04-14T00:00:00+00:00 List-Id: kaz@vision.crest.nt.com (Kaz Kylheku) writes: > > In article <2senchydgk.fsf@hpodid2.eurocontrol.fr>, > Steve Jones - JON wrote: [snip] > > > >In C assigning to an unitialised pointer will cause either a crash or > >wild behaviour and never tell you, in Ada it will crash and tell you why. > > Decent C compilers will diagnose when you have used an unitialized variable > rather than crashing at run time. My point is that the manner in which it does fail (for instance if a function is passed an unitialised pointer, or a pointer whose memory has been deallocated by another reference), it fails with a bang, Ada with a whimper. > > >In Ada you can restrict the user from assigning between incompatible types, > >you can data hide etc etc. > > This is true of C as well. Assigning between incompatible types is a constraint > violation which *requires* a diagnostic. It's all in ISO 9899:1990. A Diagnostic yes, but Ada prevents you from doing it. And this is only on weak types anyway. [snip] > >cfl = a; (assigning between two seperate int types) > > What is your point here? The two types here are compatible. You have only > created an alias name for int. In other words, C has structural equivalence > for types (other than structs). > > Why don't you see a type violation in the very declarations? > > It could easily be said that > > a = 4; > > is a type violation. After all, 4 is an integer, and a is an airspeed. A > decent, safe language would require a special conversion operator to be done on > the 4 to construct an airspeed from an integer. Does Ada require that? The Ada code would be -- Units in hundreds of feet. type Cleared_Flight_Level_Type is new integer range -10 .. 1000; -- Units in Knots, Higher values calculated as Mach. type Airspeed_Type is new Integer range 0 .. 700; Airspeed : Airspeed_Type := 4; -- 4 is a literal constant of type Airspeed_Type Cleared_Flight_Level : Cleared_Flight_Level_Type := Airspeed; This will bomb out in the compiler as the two types are difference. The literal 4 is inherited from the parent type into the new types (as are the operators +, - etc). > > In C you can do this: > > typedef struct airspeed { int i } airspeed; > typedef struct cleared_flight_level { int i } cleared_flight_level; > > There you go. The two are no longer assignment compatible with each other or > with the int type. You can still assign an airspeed to an other airspeed, and > pass it in and out of functions by value. The .i operation converts > an airspeed to an int. But this adds complexity (always having .airspeed.value) and still doesn't allow you to do correct range checking, and assignment of the value part of airspeed is still compatible with that of CFL. [snip] > Ada may have the advantage that this is required behavior. But a quality C > compiler (such as the GNU C compiler) will warn you if one or more of the > members of an enumeration are not mentioned in the switch statement. My point is that the warnings can be ignored, in Ada the code WILL fail. > > Where C messes up is in those types of errors that _cannot_ be diagnosed > or cannot be diagnosed easily. Other than that, a C implementation can be > retrofitted with all kinds of diagnostics that are not required by the > language. True, this lack of a requirement is a disadvantage, but it's > not a major obstacle. > For a large safety project the first thing that would be required is strong typing, retrofitting this would take a while I feel, and if not enforced what is the point. IME C produces more bugs than Ada, and it is harder to track down bugs in C than in Ada. And given a choice of specifiying a language for an "average" programmer I would prefer Ada every time over C (the things I have seen people do in C make my flesh creep) if they get the design wrong then the language won't help, but by preventing many of the common C errors Ada is a leap ahead. -- |Un Loup en France | Bully deification Party. One Party, one issue. | |------------Cat 1, Cha, Cha, Cha -- NERC offical drinking song----------| |----The above opinions rarely reflect my own and never my employers'----| |Do not add me to mailing lists violations will be billed for time. |