home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.lang.ada
- Path: sparky!uunet!caen!hellgate.utah.edu!peruvian.cs.utah.edu!matwood
- From: matwood%peruvian.cs.utah.edu@cs.utah.edu (Mark Atwood)
- Subject: Re: An Ada Program Does What It Says?
- Date: 4 Jan 93 08:28:27 MST
- Message-ID: <1993Jan4.082827.11773@hellgate.utah.edu>
- Organization: University of Utah
- References: <9301031530.AA17787@ajpo.sei.cmu.edu>
- Lines: 30
-
- In article <9301031530.AA17787@ajpo.sei.cmu.edu>, SAHARBAUGH@ROO.FIT.EDU writes:
- >I searched B&M's book and noted each example program whose
- >output is "indeterminate" or "implementation dependent". I
- >noted the page number on which the answer appears.
-
- (deleted)
-
- >My warning stands. Ada code looks deceptively readable. The
- >reader must understand the language translator and the
- >runtime environment to be able to correctly read an Ada
- >program.
-
- I just finished reading those books, and yes there do seem to be a lot of
- indeterminate and compiler dependent "thing" in the Ada standard. A co-
- worker and I discussed it for a while and made the observation that probably
- every language has these "gotcha"'s, they just aren't as well documented
- or understood.
-
- Stuff like expression ordering, floating point representation, concurency,
- etc, will always be indeterminate.
-
- Not to trigger yet another C vs Ada flamefest, but this expression in
- C is a classic example...
-
- r = (i++ == ++i)
-
- --
- Mark Atwood :: Being a kitten is it's own excuse.
- matwood@peruvian.cs.utah.edu ::
- The University has enough problems without being blamed for mine.
-