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,UTF8 Received: by 10.68.223.73 with SMTP id qs9mr1654709pbc.7.1344328191261; Tue, 07 Aug 2012 01:29:51 -0700 (PDT) Path: c10ni92122pbw.0!nntp.google.com!news2.google.com!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool2.arcor-online.net!news.arcor.de.POSTED!not-for-mail Date: Tue, 07 Aug 2012 10:29:50 +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: <5020d1fe$0$6566$9b4e6d93@newsspool3.arcor-online.net> Organization: Arcor NNTP-Posting-Date: 07 Aug 2012 10:29:50 CEST NNTP-Posting-Host: d2b943d4.newsspool3.arcor-online.net X-Trace: DXC=AWY`]W^B4b[=>bdbdS?M0YMcF=Q^Z^V3X4Fo<]lROoRQ8kFejVXGjA^1]:>gjRQn>F:B On 07.08.12 01:12, Vasiliy Molostov wrote: > Georg Bauhaus писал(а) в своём письме Tue, 07 Aug 2012 02:10:08 +0400: > >> 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). > > It is important since we all here working with libraries of already compiled code. We need it. Frankly, if you are working with compiled libraries made for re-use and your compiler's linking machinery cannot handle the two typical setups that are representatives of this discussion, viz. library-in-mode-optimal and library-in-mode-debugging, then maybe switch compilers but don't put all kinds of program- specific, compiler-specific, debugger-specific stuff in a public package spec. That's your quality of implementation problem with your tools, not the readers of specs of re-usable packages and that's my point. Example: ... Ada.Strings.Fixed.Move (...); ... So we have a user of package Ada.Strings.Fixed who wishes to know about Ada's Move. Would he normally have to learn---if A.S.Fixed has been compiled already---certain aspects related to translation and debugging for some implementation for some processors for some program? No! He should be able to write Move and know what Move does. Should he be able to learn about optimization opportunities when Move becomes part of some important inner loop? Yes! For example, he should be able to see whether or not Move can be inlined. But this case is special and, being a special case, should not clutter the specification of Move in Ada.Strings.Fixed! >> This is why I have >> likened optimization to calling conventions. They share the >> same degree of irrelevance from the caller's perspective. > > What is the perspective of that caller you mean? Oh, well, the standard perspective of the scenario Ada was made for: Larger pieces of software built independently such that team A using package P1, and unrelated team B also using package P1, in unrelated programs Prog_X13 and Prog_Z24 need not normally know about internals of P1, or about how P1 was translated for team B (whom they likely never heard of), or about how P1.Sub_98 is called by team A's Prog_X13, but not called in the same way by team B's Prog_Z24. Or what compiler might be used and whether or not P1.Sub_98 cannot be inlined in version 1.23 of compiled distribution of P1 for teams C, D, but not for team E. These questions are interesting in specific situations, but they should not intrude the specification of public P1.Sub_98.