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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: 1014db,1042f393323e22da X-Google-Attributes: gid1014db,public X-Google-Thread: 103376,1042f393323e22da X-Google-Attributes: gid103376,public From: Roy Grimm Subject: Re: Any research putting c above ada? Date: 1997/04/14 Message-ID: <33526CBF.41C6@cca.rockwell.com> X-Deja-AN: 234882068 References: <5ih6i9$oct$1@waldorf.csc.calpoly.edu> <5ijb0o$ajc@ns1.sw-eng.falls-church.va.us> <334d3da5.14386594@aplcen.apl.jhu.edu> <2senchydgk.fsf@hpodid2.eurocontrol.fr> <5im3an$3dv@bcrkh13.bnr.ca> Organization: Rockwell Collins Newsgroups: comp.lang.c++,comp.lang.c,comp.lang.ada Date: 1997-04-14T00:00:00+00:00 List-Id: Kaz Kylheku wrote: > > >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. There is a subtle difference you are missing here. In Ada, any type _difference_ will cause a compile time error. In C, the type _incompatibilities_ are the only things to be caught. What is the point of defining different types if you can freely assign between them? Different types are used for different purposes. Removing that checking eliminates the structure that makes Ada so much easier to debug. > >The bug count and cost of Ada is much less than that of C, just because some > >of the bugs that occur regularly in C (int a[10]; a[10] = 4; anyone ?) > >cannot > > I believe it, but you are not describing the actual advantages of Ada over C. What would you rather do? Develop software or chase after bugs? Personally, I'd rather spend my time productively producing instead of explaining to my boss why I spent two weeks on an array index that went out of bounds. Wouldn't you consider that an advantage? > >C: > >typedef int cleared_flight_level; > >typedef int airspeed; > > > >airspeed a = 4; > >cleared_flight_level cfl = 5; > > > >... > > > >cfl = a; > > 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). That's just the point. The types are not compatible. They use numbers to represent two completely different things that _must_ be separated at a conceptual level. If you've ever worked on a mission critical system, such as a flight computer, you would understand what is being talking about. > Why don't you see a type violation in the very declarations? Because numerical constants which are not typed can be assigned to numerical variables. The numerical constant is assigned a type at compile time when it is being assigned to a particular variable. Besides, the declarations probably wouldn't make it through code review. The team would make the programmer go back and put in type defined numerical constants. > 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. Why take the long road every time? Why not use a C compiler which enforces the additional required structure? It would make life so much easier. > >C is popular, it is quick and dirty, but I wouldn't like to trust my life to > >it. > > I wouldn't trust my life to any computer system, especially if it had ``Intel > inside''. Have you flown on any major commercial airplanes in the last 10 years? If so, you were trusting your life to Intel components. Their ICs have been running inside avionics equipment for years, with an extremely high success rate. Granted, the components which go into the systems are not the commercial grade chips you find in a PC, but the mil-spec version of those parts are in the flight computers world wide. > There are too many things that can go wrong _beside_ programming > errors. There is buggy hardware. There is also correct hardware which fails > to be fault tolerant. The sheer component count in a modern computer system > is astounding, as is the small size of the individual components. Would you > trust your life to a system in which an alpha particle emission can cause > unpredictable behavior? You think that modern flight computers are put on airplanes without undergoing an entire suite of rigorous tests, including pushing them beyond their limits to test the design? Do you think that the potential problems of the computers aren't planned for with redundant systems and other forms of backup? The systems can't be perfect. But stop and consider this: You hear of PCs crashing every day. It's an accepted part of daily life. Now ask yourself this: How often do you hear of an airplane having a computer problem? How often do you see it on the news? How often do you hear of an avionics computer crashing and causing a plane crash? Once or twice a year? Maybe less? How many hours do planes spend in the air compared to the problems they have? Most of the computers on those airplanes have software developed in Ada. -------------------------------------------------------------------- Voicing my own opinion, not speaking as a company representative... Roy A. Grimm Rockwell Collins Avionics Cedar Rapids, Iowa ragrimm@cca.rockwell.com