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-Thread: a07f3367d7,9983e856ed268154 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.236.133.242 with SMTP id q78mr11243926yhi.11.1344998912403; Tue, 14 Aug 2012 19:48:32 -0700 (PDT) MIME-Version: 1.0 Path: c6ni111731008qas.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin.stu.neva.ru!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Thu, 9 Aug 2012 17:18:40 -0500 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1344550724 21795 69.95.181.76 (9 Aug 2012 22:18:44 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 9 Aug 2012 22:18:44 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Received-Bytes: 3654 Date: 2012-08-09T17:18:40-05:00 List-Id: "Robert A Duff" wrote in message news:wccr4rkqed5.fsf@shell01.TheWorld.com... > "Randy Brukardt" writes: ... > If you like, show us an example of one of these "fails to link" > cases. Or don't bother -- it's really not that important. Well, I don't want to waste more time on this, but I'm annoyed enough that I will. First, we're talking about a compilation dependence here, not an elaboration or semantic dependence. That's not defined formally by the Ada 95 language, but of course it's necessary to any implementation. (I believe it was formally defined in Ada 83.) Anyway, consider: package P is function F return Boolean with Inline; end P; package body P is function F return Boolean... end P; with P; procedure Q is begin if P.F then ... end Q; Here, Q has a compilation dependence on the body of P. If the body of P is recompiled, then Q also has to be recompiled. If it is not, then the program must not be allowed to link. (That would be a violation of 10.1.4(5)). Also note that 10.1.4(7/3) talks about "removing" compilation units that contain calls on inlined units when a new copy of the body is added (and "preexisting versions" of the body are removed). This has the effect of a compilation dependence. (For Janus/Ada, we don't "remove" units, but we do refuse to bind units that contain references to old versions. I've always presumed that that was a correct implementation of these two rules.) IMHO, compilation dependences should be given in the visible part of the package (preferable in the context clause), so that the 1% of Ada programmers that compile files by hand can accurately find the dependences. Requiring the use of implementation-defined tools like GNAT's Gnatmake or Janus/Ada's COrder is obnoxious. Thus "Inline" needs to be given in the visible spec. If 10.1.4(7/3) didn't exist, then Inline would not need to be given in visible spec. But as I noted elsewhere, I don't think Inline should be given anywhere -- compilers can figure out when to Inline better than any human can. Hints about the amount of space expansion allowed for the entire program and the relative importance of particular subprograms would be much more valuable. Randy.