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.4 required=5.0 tests=BAYES_00,FORGED_MUA_MOZILLA autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,9983e856ed268154 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.180.24.165 with SMTP id v5mr44568wif.1.1344413413873; Wed, 08 Aug 2012 01:10:13 -0700 (PDT) Path: q11ni23154210wiw.1!nntp.google.com!goblin2!goblin.stu.neva.ru!news.teledata-fn.de!newsfeed.arcor.de!newsspool3.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Wed, 08 Aug 2012 10:10:14 +0200 From: Georg Bauhaus User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? 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> In-Reply-To: Message-ID: <50221ee4$0$6580$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 08 Aug 2012 10:10:12 CEST NNTP-Posting-Host: ebca301a.newsspool3.arcor-online.net X-Trace: DXC=X1n8L6SmG<9RLigj];iP=8McF=Q^Z^V384Fo<]lROoR18kFejV8MHB5Jm;lGP5JG:\e7 X-Complaints-To: usenet-abuse@arcor.de Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2012-08-08T10:10:12+02:00 List-Id: On 08.08.12 03:48, Shark8 wrote: >> it is not important to know >> the convention of an import when writing the call (of the >> Ada subprogram from the package spec). > > No, that's not only wrong but _very_ wrong. Conventions are *vital* to a specification. Later, you said > and is therefore properly placed into the specification (or possibly private section if you're providing an API layer). Yes, these aspects could be written in the private part of a package, which is what I had suggested. So that compiler thingies and optimization issues and even compiler specific pragmas would not litter the public part of a package spec. They do that, IMHO, if you use aspect notation for pragma(tic) stuff. > Let us consider just one subprogram: > Procedure Add(Object : In Out Our_Type; Value : In Integer); Do the call statements change, though? Add (Some_Object, 42); How do you, the programmer, have to change the above call in order for the convention to be handled? You don't need to change the way you write the call. Calling conventions are for the compiler of high level languages, for the most part. There are circumstances where the convention becomes important, and the compiler should tell us. Optimization can become important, too, and even then a compiler like GNAT might warn about things that have been optimized away. But both do not normally change the way a programmer writes a correct call in source text. So, WRT writing call statements, the interface of a subprogram can be understood without looking at its calling convention, or considering implications for speedier execution. > That is, the convention drastically alters the interface, Not at all. The calling convention alters the translation process, and, possibly, its outcome. The convention does not alter the way the programmer passes parameters in calls. The interface, in Ada, would be a source text thing. (And both Pascal compilers and C compilers might not even be using a stack when translating the above call, for example, if both parameters can be passed in registers, and the return address lives in a special register, etc.. Or when the hardware does not even have a stack, but still allows implementations of either language.)