Re: Should Inline be private in the private part of a package spec?

["Randy Brukardt" <randy@rrsoftware.com>]

"Georg Bauhaus" <rm.dash-bauhaus@futureapps.de> wrote in message 
news:502040c0$0$9510$9b4e6d93@newsspool1.arcor-online.net...
> On 06.08.12 23:52, Georg Bauhaus wrote:
>
>>> 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.
>
> And, just like it is not normally important to know optimization
> issues when writing a call,

That's only because most optimizations don't change the calling conventions.

>  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 definitely not true. The convention affects legality as well as code 
generation.

> This is why I have
> likened optimization to calling conventions. They share the
> same degree of irrelevance from the caller's perspective.

If optimizations changed the calling convention, then they would indeed have 
to be given in the specification. (Indeed, I would much prefer that that was 
the case; Janus/Ada simply does not do any optimizations for which the 
optimization level would matter, and this is the major reason. Otherwise, we 
would need compilation dependencies like Inline does, and the information 
would have to be in the specification.)

I detest the idea of separate project files like GPR; most of that 
information should have been in the Ada source (having it there makes the 
code more portable to other Ada implementations). The need for 
meta-languages always shows a lack in the original language.

                                              Randy.