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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f495c7652c09dd8c X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: Does this model work ? Date: 1999/05/20 Message-ID: <37446337.5F60D8F1@pwfl.com>#1/1 X-Deja-AN: 480235678 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <373e38e2.31311363@news2.ibm.net> <7hhj6q$cjn$1@nnrp1.deja.com> <01be9ee1$eca9be10$022a6282@dieppe> <373E24C3.D77A6837@easystreet.com> <7hp1g8$f9n$1@cf01.edf.fr> <37408152.C65D85E8@pwfl.com> <7i1cad$4md$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: diespammer@pwfl.com Newsgroups: comp.lang.ada Date: 1999-05-20T00:00:00+00:00 List-Id: Robert Dewar wrote: > > First, surely no one would use Standard.Integer if they > have any concern for portability. > The problem is often one of not knowing that you are supposed to have a concern for portability. Sometimes you build things believing that it just has to function in this single environment and that it will never be called on to move. Or you believe it will be thrown out long before it ever becomes an issue (Witness, Y2k! :-) > Second, I agree that specifying sizes for any data to be used > externally is quite reasonable, and in this sense I agree > with the above quote. > > The point is that well written code should be as easy to > port from 32- to 64-bits as from any one Ada 95 compiler > to another. > And then you have to ask the question: "What constitutes 'well written' when portability is a concern?" Certainly, predefined types are O.K. for internal computations within known limits. User defined types with rep clauses where I/O or interaction with other devices are issues. Information hiding is important for device dependencies, etc. so that the parts which can't be portable are at least isolated and easy to replace. There are quite a few ways to shoot yourself in the foot. I don't know that anybody has come up with a list of steps or guidelines that someone can use as a kind of cookbook for insuring portability. It would be handy to have. Without one, I think the best defense is being sensitive to what compilers do and how things might vary from one implementation to the next. Ada95 certainly makes this significantly easier than other languages and we've had some porting experiences around here that tend to bear this out empirically. MDC -- Marin David Condic Real Time & Embedded Systems, Propulsion Systems Analysis United Technologies, Pratt & Whitney, Large Military Engines M/S 731-95, P.O.B. 109600, West Palm Beach, FL, 33410-9600 ***To reply, remove "bogon" from the domain name.*** Visit my web page at: http://www.flipag.net/mcondic