Re: pragma/aspect Import, Convention parameters

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

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:1xhfjepw437zd.137i8eiplc5lt.dlg@40tude.net...
> On Thu, 13 Aug 2015 15:32:23 -0500, Randy Brukardt wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:1215a889y9uxf$.1nolkb1ctch79$.dlg@40tude.net...
>>> Why is it an identifier?
>>
>> Dunno. That's what Ada 95 defined, and we've never had a request to 
>> change
>> it.
>
> Maybe now? It is not a big change and as much as I hate if-then-else
> expressions they could be handy here.

As always, send a description of the problem and proposed solution (not just 
the solution, 'cause that will just get put in the dusty drawer never to be 
seen again) to Ada-Comment and it most likely will get considered.

>> In my experience (which is mostly with rather low-level stuff), there is 
>> a
>> lot more different than just the convention when changing between Linux 
>> and
>> Windows (subprogram names, parameter values, etc.)
>
> In these days most upper level libraries are more or less compatible
> regarding their API. The main problem is actually names and conventions
> because most of them have them build with Visual C for the Windows part 
> and
> mimic Windows API, which are StdCall.

That's of course the difference in our experience. I'd almost never use 
"upper-level libraries" for anything; I want as much code as possible that I 
can fix (which means it has to be Ada code at least nominally in our 
control). That's why Claw is the sort of binding that it is, directly to 
Win32.

>> So it's not much of a
>> hardship to use separate thin bindings for each -- the differences are
>> reconciled in the thick binding anyway.
>
> Keeping two versions of *.ads is excessive and a hell of maintenance.
> Independently of whether you have thick bindings or not, you have to have
> thin bindings first.

Right. It *is* a hell of a lot of maintenance -- that goes with the 
territory -- and no one wants to build tools that help. (Conventional 
version control is actively harmful in this, and the C "solution" of a 
preprocessor is a guaranteed trip to unmaintainable spagetti code.) Of 
course, it's possible that one *cannot* write a usable tool that would help 
(I wasn't able to solve the problem adequately for our own use, and I have 
tried).

...
>> We side-stepped the problem for Claw by not supporting any other targets
>> than Windows. :-) It would have been a lot worse had we wanted to support
>> (say) GTK on Linux.
>
> Yes.
>
> However GTK is not a big problem because it has same external names under
> Windows and Linux. For really few exceptions GTK's GIO had I used GCC
> linker weak references to avoid contamination of *.ads files.

There is no way we would have used GTK on Windows. The entire purpose of 
Claw was to give applications the Windows native look-and-feel. I've yet to 
see any GTK application that comes remotely close.

A Linux version of Claw would have existed to emulate as much of that 
Windows look-and-feel as possible on Linux. I probably would have based it 
on GTK as X11 is a nightmare, but it would have been insane to run a program 
that *emulated* the Windows look-and-feel on Windows when a simple 
recompile/relink would have given one the actual look-and-feel.

But I've actually been leaning toward the "portable" version of Claw being 
based in some way on HTML -- essentially what David Botton has been doing 
with Gnoga. (So it probably will never happen, as there doesn't seem like 
there would be any reason.)

                                              Randy.