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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no 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.66.90.5 with SMTP id bs5mr1208345pab.35.1344851911651; Mon, 13 Aug 2012 02:58:31 -0700 (PDT) Path: p10ni48093485pbh.1!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!novia!newsfeed.yul.equant.net!npeer.de.kpn-eurorings.net!npeer-ng0.de.kpn-eurorings.net!news-feed.eu.lambdanet.net!news.bcc.de!newsfeeder.ewetel.de!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Shark8 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Tue, 7 Aug 2012 18:48:30 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <501bd285$0$6564$9b4e6d93@newsspool4.arcor-online.net> <502005b6$0$9510$9b4e6d93@newsspool1.arcor-online.net> <50203ca2$0$9512$9b4e6d93@newsspool1.arcor-online.net> <502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net> NNTP-Posting-Host: 69.20.190.126 Mime-Version: 1.0 X-Trace: posting.google.com 1344390511 29326 127.0.0.1 (8 Aug 2012 01:48:31 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 8 Aug 2012 01:48:31 +0000 (UTC) In-Reply-To: <502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=69.20.190.126; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC User-Agent: G2/1.0 X-Received-Bytes: 3473 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-08-07T18:48:30-07:00 List-Id: On Monday, August 6, 2012 4:10:08 PM UTC-6, Georg Bauhaus wrote: > On 06.08.12 23:52, Georg Bauhaus wrote: >=20 > >> Why you have decided that calling convention is an optinization? > > > > What the program does is not a matter of whether or not > > some subprogram needs calling convention Ada or StdCall or > > some such. Hence, from the perspective of the caller, > > knowing the calling convention of an import is distraction > > at best. >=20 > And, just like it is not normally important to know optimization > issues when writing a call, it is not important to know > the convention of an import when writing the call (of the > Ada subprogram from the package spec). This is why I have > likened optimization to calling conventions. They share the > same degree of irrelevance from the caller's perspective. No, that's not only wrong but _very_ wrong. Conventions are *vital* to a sp= ecification. Let us consider just one subprogram: Procedure Add(Object : In Out Our_Type; Value : In Integer); Now with respect to this subprogram if "Pragma Convention( C, Add );" is ap= plied then the parameters are pushed onto the stack Right-to-Left, and the = calling-code is to handle cleanup. HOWEVER, if "Pragma Convention( Pascal, = Add );" was applied the parameters would be pushed Left-to-Right and the fu= nction itself would handle the cleanup. Even ignoring callee/caller cleanup there's a lot of difference here -- one= 's stack looks like this: Object, Value The other's like this: Value, Object That is, the convention drastically alters the interface, and is therefore = properly placed into the specification (or possibly private section if you'= re providing an API layer).