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,b16c9883f36bc904 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2000-08-14 21:56:46 PST Path: supernews.google.com!sn-xit-02!supernews.com!nntp-relay.ihug.net!ihug.co.nz!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed1.earthlink.net!newsmaster1.prod.itd.earthlink.net!newsread2.prod.itd.earthlink.net.POSTED!not-for-mail Message-ID: <3998CDAB.B12A271F@earthlink.net> From: "Robert I. Eachus" Organization: The MITRE Corporation X-Mailer: Mozilla 4.73 [en]C-19990120M (Win98; U) X-Accept-Language: en,pdf MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: WinNT ADA compilers comparison References: <3976C68A.12386D00@cadwin.com> <8l7fff$9kb$1@front1.grolier.fr> <3A92E737.E690906A@free.fr> <3978041A.EB0F8FCE@cadwin.com> <8lcgbi$gvb$1@front5.grolier.fr> <397C03F9.AF6DF60F@cadwin.com> <86zon5aio7.fsf@acm.org> <8m8psc$ef6$1@nnrp1.deja.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 15 Aug 2000 04:56:28 GMT NNTP-Posting-Host: 63.24.60.151 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.prod.itd.earthlink.net 966315388 63.24.60.151 (Mon, 14 Aug 2000 21:56:28 PDT) NNTP-Posting-Date: Mon, 14 Aug 2000 21:56:28 PDT Xref: supernews.google.com comp.lang.ada:138 Date: 2000-08-15T04:56:28+00:00 List-Id: n_brunot@my-deja.com wrote: > In comparison to others compilers (not only Alsys ADA83) Gnat produces > incredibly huge executables when you make intensive use of generics > (using a lot of generics is a quite normal and desirable thing in ADA > according to us) > We of course use generics (and generics of generics ....) which is may > be one of the most important and powerful ADA features, allowing you > not spending your time writing more or less the same code, and keep > strong compiler check. During the Ada 9X Requirements process, those of us at MITRE who were involved with supervision of government contracts had very few corporate, as opposed to individual comments, on the proposed requirements. The one thing that we all felt strongly about was that there were "shortcomings" in the Ada language that should not be fixed. Why? Because when a project ran into one of these "major problems" with Ada, they would complain about the language, we would get called in, and in most cases a design fix that was very inexpensive AT THAT POINT IN THE PROJECT would eliminate both the major design problem and the problems that the contractor was attributing to the language or the compiler. One simple example is "slow compilation times." If your project is making changes every day that require recompiling a substantial fraction (or all!) of the source code, then the problem is not that Ada has these nasty recompilation rules, it is that your design is not using information hiding correctly, and that the final code will almost certainly be unmaintainable. Another example, and the one that you seem to be tripping over, is proper use of generics. There is noting wrong with generics nested in generics, and generic instantiations that instantiate other generics, etc. But you need to know for each generic and each instantiation whether or not the compiler should do inlining, and where. But isn't that an implementation detail you say? Sure it is, and it is nice that the Ada language is designed so that changing those decisions can be done by changing a couple of pragmas in the source code. But the decisions that can and should be delayed until later in the project do not include code size limitations and timing of key threads. Those issues need to be thought out during the preliminary design process and communicated to all members of the team, not just to the design team. If those broad brush decisions are made correctly, and communicated to the team, you won't have either code bloat or slow execution surprises. But no matter how intelligent the compiler is on the issue of inlining and generics, the compiler doesn't know what the intent of the design team is. Pragmas and compiler switches can communicate that information to the compiler, but if the design team hasn't considered those issues, how can the compiler be expected to make those decisions correctly. (Also there are cases where what you really want to do is to use generics to express templates, and the body of the generic template needs to be written as a template. The generic subprogram, or more usually, the subprograms in a generic package, will be designed to be inlined, but most or all of the actual code will be in subprograms that are non-generic, and not inlined. The Gnat Text_IO library has some good examples of this.) So if your compiler is making incorrect implementation decisions, the fault is usually not in the compiler, but in the directions that it is given. And even when the compiler is guessing right, you should still tell the compiler what to do, and document it carefully, if the decision is a key part of the overall design. This is why the usual advice is to use pragmas, often with very restricted scopes, rather than compile-time switches. The pragma puts the documentation where it belongs--and will be seen by maintainers. This is one reason why pragmaa Unsuppress is being standardized. It allows the programmer to document that a particular exception is an expected part of this piece of code, and any necessary checks should made here, even if the check is turned off globally by a pragma or by a compile-time switch.