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: 103376,9983e856ed268154 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,UTF8 Received: by 10.180.96.42 with SMTP id dp10mr1414354wib.2.1344294592930; Mon, 06 Aug 2012 16:09:52 -0700 (PDT) Path: q11ni353911wiw.1!nntp.google.com!goblin3!goblin1!goblin2!goblin.stu.neva.ru!aioe.org!.POSTED!not-for-mail From: "Vasiliy Molostov" Newsgroups: comp.lang.ada Subject: Re: Should Inline be private in the private part of a package spec? Date: Tue, 07 Aug 2012 03:09:51 +0400 Organization: None 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> NNTP-Posting-Host: Xw13RWgh8yxgPSv0x3+H9w.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.01 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: Quoted-Printable Date: 2012-08-07T03:09:51+04:00 List-Id: Georg Bauhaus =D0=BF=D0=B8=D1=81=D0=B0=D0= =BB(=D0=B0) =D0=B2 =D1=81=D0=B2=D0=BE=D1=91=D0=BC =D0=BF=D0=B8=D1=81=D1=8C= =D0=BC=D0=B5 Tue, = 07 Aug 2012 01:52:34 +0400: >> They will affect already compiled modules. > > That's not relevant to specifying subprograms in public parts > of a package spec. A subprogram spec is about how to write > correct calls of the public subprogram. BTW, I have menant the same - modules that have used this inlined = subprogram and already compiled. >> As you might know Ada aimed to minimize recompilations. > > Quality of implementation issue. I think Bob Duff has also explained > a few times that incremental compilation might would be a better > choice if minimizing recompilations is a goal. ? I dont see your replica is related to recompilation and inlining. >> 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. Caller should be possible to establish any property to link this = subprogram to its own image (link it from a library or from a standalone= = compiled module). If not - linking is not possible. >>> Optimization switches are not usually >>> part of subprogram's public specifications either. >> >> Why (convention) is not a part? What is usually? > > I'd expect aspects to let me know what a subprogram does > if I call it with suitable parameters. Aspects of how that > is going to be done in terms of processor instructions > are of no concern at this point. Unclear, or I cannot see any relation to convention/inlining. What are you about? Rook gambits are tied? >> Yesterday I wrote some code and it has specs along with inline, just = = >> after subprogram spec. >> Today you said that it is not usual. Not usual for whom? > > The focus is on the public part of a package spec, to be read by > other programmers. Information hiding might ask for compiler > hints and the like to be put somewhere they do not clutter > the text that conveys meaning, that is, explains what a > subprogram does, and how to call it. Inline can well be hidden > here. The question was - WHY? And for what benefit? > Inline gives the compiler permission to inline a subprogram, > but it does not specify anything that a programmer needs to > know in order to call the subprogram. The calls he or she writes > will be invariably the same, no matter what the inline status > will have turned into in some executable program. No, when I call inlined subprogram I can see that this is inlined and I = = can not use hardware breakpoint, I can not use address of such subprogra= m = widely in my writings, and I can suppose that internal variables if they= = are shared across inlined copies can cause a jam with locals, and I can = = not use it as an interrupt handler. From other properties I can take mor= e = assumptions what can be inserted in my code. > Writers' convenience usually is a sign of less than co-operative > software design, pardon the expression. The focus is on readers' > convenience. By that reader I mean not only human, but also a compiler, a tool for UM= L = processing, and the rest. I think that your approach is entirely against= = cooperation. Sabotage. > When modelling, pragmatic hints seem all the more irrelevant. > When a UML tool starts to dictate how package specifications > should be made, I start to worry a little. Seem for whom? your words sound like stylist, and not a designer. Me = dictate to my UML tool what to be made. So you should not be worry even a little, since it is not related to you= . The question was - why you have named 'convention' as one of optimizatio= ns? > When I pay a programmer of a package to write a package > that I can use, I couldn't care less about whether he or she > finds it profitable or convenient to have all aspects/pragmata > in one place. I want to be able to read the spec, learn about > how to call the subprograms, and be done. I suppose as you pay - you dont write them. Probably your way - is to pa= y = for all the program (and related subprograms) entirely, without making things = stressed for people (or tools) with which you dont share their convenience. Buy ready to use thing - its much less nervous! > When I write just the specification and the body should be > written by someone else, then it seems rather premature > to write Inline aspects and request that they be considered > just as much specification as the parameter types or expressions > from predicate calculus stating relations between them. Indeed. Premature. If you design is weak and there is nothing to supply = it = is indeed premature to write aspects at all. If you know what are you doing (and every contractor's requirement expre= ss = such knowledge) - why not? > OTOH, if the writers of the body decide that one of the > subprograms might be expanded inline, they can add a pragma > (or brick, as you say) as needed *without* changing the > specification of this subprogram. This is too serious action to add a brick without approval. Have you tri= ed = it on railroads? How about Q&A team with their set of tests that meet some kind of such a= = small extention brick at testing stage? >> A good way is to use Inline as a configuration pragma, > > Since Inline applies to program units, that won't work. I have pointed out to pragma Eliminate. > Moreover, pragma inline, if used heavily, can be counterproductive, > for example, if it makes register allocation be at odds with > the compiler's other ideas. For example, sometimes GCC's vectorizer > seems to require that a function *not* be inlined, in order to > increase overall speed of execution. > > The library's developers can only disable inlining if they > removes pragma Inline / aspects, or if the tool chain can be > incapacitated in other ways. Do you plan to add here also excerpts from Yellow Pages? I have a copy, = = btw. The question is still open: Why You have insist that convention is an = optimisation? -- = =D0=9D=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BD=D0=BE =D0=B2 =D0=BF=D0=BE=D1=87= =D1=82=D0=BE=D0=B2=D0=BE=D0=BC =D0=BA=D0=BB=D0=B8=D0=B5=D0=BD=D1=82=D0=B5= =D0=B1=D1=80=D0=B0=D1=83=D0=B7=D0=B5=D1=80=D0=B0 Opera: http://www.oper= a.com/mail/