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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: C++ Standardization (was: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/21 Message-ID: X-Deja-AN: 191075487 references: <54es3s$2dv@lex.zippo.com> <326B6DFD.732B@ainslie.com.au> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-21T00:00:00+00:00 List-Id: Bob Duff said "If you were the last company on Earth using Ada, then you would not have a competetive advantage -- you would be stuck shovelling money into the last Ada compiler on Earth. And it would be buggy and inefficient, and the latest and greatest configuration management tools wouldn't work with it." Unnecessarily pessimistic I think, in several respects. Sure this may be true if you are talking about a proprietary compiler built and maintained in a vacuum, but in fact it takes relatively little use of Ada to support the continued development of GNAT, and the reason that is achievable is that we maintain open systems standards precisely so that the "latest and greatest configuration management tools" will work with minimial or even zero effort. We are committed to GNAT becoming the best compiler for any language, period. Sure it would be nice if Ada really took off and became super succesful, but our business plan does NOT depend on this hapenning, and GNAT can continue to prosper and improve without depending on huge amounts of resources. I think this is important. People have mentioned reently that top management often worries about the future of Ada. If your only response is to depend on the hope that Ada will become wildly successful, then if I was in that position, I would ban Ada use immediately. It is not that I am sure this will not happen, it is that I certanly cannot say I am sure it will happen, and relying on super sucess for Ada is far too risky. It is much more convincing to be able to demonstrate that there will be at least one usable high quality technology that allows the potential of Ada 95 to be realized REGARDLESS of whether or not Ada succeeds in grabbing a huge market share. Ironically, this assurance that such success is not required is one thing that will greatly help to increase the chances of such success. I can't speak for any other Ada vendors, but Ada Core Technologies is very optimistic about its future, and we see ourselves as being around for the long term, and succeeding in continuing to improve the quality of the compiler. Shortly we will release 3.07 which has some substantial improvements. In fact, why not? here is a preview of the new features: GNAT now checks for the case of a body file present when the spec does not require a body. GNAT always diagnosed the error when the body was compiled, but if only the spec was compiled, the suspicious body was ignored. The presence of a body file when no body is allowed is now considered an error in Ada 95 mode, and a warning in Ada 83 mode. Packed arrays with bounds depending on a discriminant now work correctly The DEC pragmas have been implemented. Those of interest to GNAT ports in general are as follows (see below for full documentation) Common_Object Component_Alignment Export_Function Export_Object Export_Procedure Export_Valued_Procedure Import_Function Import_Object Import_Procedure Import_Valued_Procedure Suppress_All The DEC attributes have been implemented. Those of interest to GNAT ports in general are as follows (see below for full documentation) Bit Machine_Size Null_Parameter Type_Class Attribute Mechanism_Code allows determination of the parameter passing mechanism chosen by GNAT, as possibly controlled by the Import, Export and C_Pass_By_Copy pragmas. Pragma Extend_System allows transparent extension of package System to accomodate definitions from other implementations of Ada. Machine code insertions have been completely implemented. A new section in gnatinfo.txt describes the use. Both code statements as such, and also intrinsic calls are available. The latter allow interspersing machine instructions in Ada code. Inlining of machine code procedures is fully supported. The pragma C_Pass_By_Copy is implemented in a manner that is completely compatible with the Intermetrics implementation of this pragma. The default mechanism for passing records to foreign convention subprograms is now by-reference. This can be modified by either use of one of the DEC extended Import/Export pragmas, or by use of the C_Pass_By_Copy pragma. Further extended support for representation clauses, including more cases of misaligned fields, and non-standard layouts. Record representation clauses no longer require that the position of all fields be specified. Pragma Error_Monitoring has been removed. This pragma was not used and had a number of conceptual and implementation problems. And of course that is 3.07, we are hard at work on 3.08, and have already added many interesting new capabilities that will show up in 3.08. Not listed in the above list is the general improvements in reliability and performance that come from steady work on these aspects. GNAT is still in its infancy if we take a long term view, which we do! We have many ideas for improving its performance and realiability and functionality, and fully expect to see these ideas realized in coming years.