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,3cd797aa3bdcb07b X-Google-Attributes: gid103376,public From: Marin David Condic Subject: Re: performance of Generic and strings Date: 1999/08/13 Message-ID: <37B42F56.CF724A15@pwfl.com>#1/1 X-Deja-AN: 512276823 Content-Transfer-Encoding: 7bit Sender: condicma@bogon.pwfl.com References: <37B18AB6.BBAEF44A@pwfl.com> <7osak8$gph$1@nnrp1.deja.com> <37B1B634.543D131D@pwfl.com> <7ovq7d$km$1@nnrp1.deja.com> X-Accept-Language: en Content-Type: text/plain; charset=us-ascii Organization: Pratt & Whitney Mime-Version: 1.0 Reply-To: e108678@pwflcom Newsgroups: comp.lang.ada Date: 1999-08-13T00:00:00+00:00 List-Id: Robert Dewar wrote: > > > It > > also greatly reduces verification problems, which is a > > tremendous concern around here. > > I am not at all sure that it reduces verification problems. > Obviously if you are doing only one instantiation, it greatly > increases the problems, because the code is so much more > complex, and will rely on a lot of indirect subprogram calls, > for the thunks, always a big worry for verification environments > (some verification protocols simply prohibit indirect calls > completely). > The problem is not so much a technical one as it is a procedural and managerial one. If you go to the trouble of verifying a normal subprogram by running the code with a variety of test cases, this takes a fair amount of time and money. From one release to the next, so long as that module has not been touched, you can presume the verification to remain valid. (Yes, we can always generate scenarios where the calls change and something that didn't blow up, now does, but that's more of an integration issue.) You'd very much like to do the same thing with a generic, but in an expansion situation, it generates a whole new set of bits every time it is instantiated and you now have to do something to demonstrate that this new set of bits is correct. Seeing that the code didn't change from one release to another tells you very nearly nothing about the validity of your prior verification efforts. Whereas if the code is shared (difficult as that may be) you have one set of bits which you can run a verification suite on and - to the extent that your test scenario is useful - you can feel comfortable that no change in the source module means that this verification remains valid. Of course a lot depends on how serious you need to treat the issue of verification. :-) And we can always throw in the monkey wrench of observing that with some compilers, given the same source code, a different set of bits may be generated depending on execution conditions at the time. That *really* makes our configuration management people lose sleep at night! :-) Thanks for the useful info on what compilers do with generics. 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.mcondic.com/