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,c1983ae2deb642ab X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-05-25 03:58:00 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dewar@gnat.com (Robert Dewar) Newsgroups: comp.lang.ada Subject: Re: Ada -vs- GNAT Date: 25 May 2002 03:58:00 -0700 Organization: http://groups.google.com/ Message-ID: <5ee5b646.0205250258.7502fb36@posting.google.com> References: NNTP-Posting-Host: 205.232.38.244 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1022324280 15023 127.0.0.1 (25 May 2002 10:58:00 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 25 May 2002 10:58:00 GMT Xref: archiver1.google.com comp.lang.ada:24743 Date: 2002-05-25T10:58:00+00:00 List-Id: tmoran@acm.org wrote in message news:... > >from the Booch Components, which are meant to be, and to a large > >extent are, compiler-independent. On the other hand, given that GNAT > >is my preferred compiler (for all sorts of reasons), I felt quite > >happy to use 'Object_Size when appropriate. In fact Object_Size is most certainly an essential capability. It was one of the very unfortunate last minute changes to the Ada 9X spec that you cannot specify size for subtypes. People are always very confused by the fact that the size attribute is called subtype specific, but you cannot apply it to subtypes. What happens is that the compiler is free to assign different sizes to subtypes (and in some cases forced to by the standard), but the user has no control whatever over these sizes. > Which is like being a little bit pregnant. It means the potential user > must: switch to Gnat; start a new branch of the update tree; or not use > your package. It makes life simpler for you, harder for your users, and > (possibly) richer for ACT. Just remember all those consequences of your > decision. Obviously in general packages you do not use non-portable constructs unless needed. But I want to emaphasize again that there are many many ways of making code non-portable. Annex M has a lot of entries in it. In our experience when porting from one compiler to another, attributes and pragmas are unlikely to be a source of major difficulties, compared to rep clauses and non-portable use of constructs like address clauses. It is of course perfectly reasonable to make packages GNAT speicific if there is some particular gain in doing so. You just have to be sure that such a package is clearly marked. For example, some packages are designed to work in an intimate way with the GNAT run time, and obviously such packages are likely to be GNAT dependent. As for portability, you are not doing so badly if you make something GNAT dependent, since GNAT is implemented on a wider range of machines than any other compiler. Indeed I would think a much more limiting decision is to use packages that are tied to one particular machine or proprietary operating systems.