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: 103376,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: heatwole@his.com (Kevin D. Heatwole) Subject: Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/12 Message-ID: X-Deja-AN: 188959395 references: <01bbb57f$7fb59020$72663389@billn.logicon.com> <325BC3B3.41C6@hso.link.com> <325BED6A.63F4@itg-sepg.logicon.com> <325EB65B.132F@thomsoft.com> content-type: text/plain; charset=ISO-8859-1 organization: Heller Information Services, Inc. mime-version: 1.0 newsgroups: comp.lang.ada Date: 1996-10-12T00:00:00+00:00 List-Id: In article , dewar@merv.cs.nyu.edu (Robert Dewar) wrote: >"Gee, I thought the Annexes were OPTIONAL components of validated compilers, not >that compilers without the >annexes were SUBSET(!!!) (implied "NOT REALLY FULL Ada 95") compilers." > > Of course it is definitely the case that the annexes are optional, in the > same sense that the optional modules of COBOL, e.g. the Report Generator, > are optional. So a compiler that does not implement all the features > of the language is still meeting the conformance requirements, just as > would be the case with COBOL. No one is saying that such an implementation > is not a valid Ada 95 implementation. > > By subset, I simply meant a subset of the full language capabilities in the > RM. There is nothing wrong with subsetting the language by leaving out the > annexes if the application does not need the full language! I would > certainly think that most people would think that "full language" meant > everything in the RM, but you can use any term any way you want! Certainly > for us, full language *does* mean all the capabilities in the RM. > Well, I have used all the Ada95 compilers (or have talked to people who have) and I got to say that this whole discussion is a bit irrelevant at this point. There simply is no Ada95 compiler that implements all the core requirements of the language, let alone worrying about whether the optional annexes are optional. GNAT certainly fails to compile many legal Ada95 programs and allows many other illegal programs (I run into this just about every day now since people are porting code written with GNAT to our PowerAda compiler). I don't mean to pick on GNAT here since all of the compilers are in the same boat here. I would expect this situation to continue for a year or so until the current compilers mature and get the bugs shaken out. The question for end users to decide now is not whether they require the "full language" (because if this is the requirement, they are left with no options), but whether the compiler is mature enough and implements enough of the language to meet their needs. During this period of transition to Ada95 from Ada83, I would expect that it is, by far, more important to have a close working relationship with your vendor than whether the vendor claims to have implemented the "full language". By the way, for those not familar with the current validation process, the US government requires that compiler vendors demonstrate compliance to a set of minimum requirements for compilers sold to the government. This compliance is demonstrated for Ada95 by running a suite of tests called the ACVC tests. Just like the Ada compilers it tests, this test suite is currently in the process of evolving/maturing. The first version of this test suite for Ada95 compilers was called ACVC 2.0 and compiler vendors started validating their compilers under this test suite late last year (OC Systems validated our PowerAda compiler in December). This test suite did not require a compiler to pass all the tests in the suite. In fact, any validate-able Ada83 compiler could be validated with ACVC 2.0 without having to implement a single Ada95 feature. Most vendors chose to validate by passing all the applicable core language tests, but one vendor chose not to run any of the tests that use Ada95 features. Also, the ACVC 2.0 test suite isn't a very complete test suite for testing Ada95 features. Early this year, an incremental version of ACVC 2.0 went into place for vendors validating new Ada95 compilers on new platforms. This version is called ACVC 2.0.1. ACVC 2.0.1 didn't add any new tests to the test suite but did fix the bugs in the existing ACVC 2.0 test suite for tests that had been withdrawn from ACVC 2.0. One important policy change for this test suite is that Ada95 compilers validating under this test suite now have to pass a few Ada95 tests to be validated (an Ada95 compiler must now pass either the OOP tests or the Real-Time tests). The "real" Ada95 validation suite will go into place for the 2nd quarter of 1997 with the arrival of ACVC 2.1. This test suite is still being developed, but it should contain tests for almost all testable features of Ada95 (of any consequence). Vendors will have to demonstrate compliance to all core requirements of the Ada95 language in order to get a validation certificate. Compliance to the optional Ada95 annexes will also be optionally tested. Passing this test suite will be a real accomplishment for Ada95 compilers. Users can be assured that Ada95 compilers that have been validated under ACVC 2.1 are reasonably complete. So, during this transition period, I would be very careful about relying on claims of "validated Ada95" or "full language support". These claims are largely "marketing hype". Users will have to do their own research or evaluation testing to determine whether a particular compiler is mature enough and implements enough of the Ada95 language for their own particular needs. Fortunately, many of the current Ada95 compilers are quite useable now, even if they don't support the "full language". Speaking for myself, Kevin Heatwole OC Systems, Inc.