Re: Re-Marketing Ada (was "With and use")

["Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca>]

Marin David Condic wrote:
> Let me conclude with this: I have no opposition to a C/C++ header file 
> translator. It removes one more roadblock to using Ada. I have doubts 
> about how achievable it is because header files are always context 
> sensitive and Ada package specs are not. Perhaps the best that can be 
> done is to generate a binding 90% of the time and puke over the rest of 
> them. 

That is the likely result. But with the help of hint files,
you can probably direct thinbind to resolve or ignore the
pukey code within the header file.

> I also have doubts about the relative food value of having one. It 
> would be useful, 

Based upon the posts that I have seen over the last few years
here in cla, I would say that interfacing to C is not easy
for many Ada users.

The one problem that I constantly have to hand craft a solution
to is the interfacing with C components on different platforms.
A value in a C header file for FreeBSD may or may not be the
same as the same on a Linux host. That same value (or type
size) may differ again on a Linux/Alpha host for another.

This aspect is a royal pain. To make APQ portable (for example),
I have to resort to compiling short little C test programs
to generate Ada specs, or portions thereof. Sometimes shell
scripts massage that output further. A tool, like thinbind
could reduce this effort considerably to one line in a
Makefile. At least to me, this is a big issue.

> but would the effort be better spent coming up with 
> something that makes Ada *more* attractive to people using C/C++ in some 
> problem domains? 

This is a difficult call. But I know this much for sure:

Every open sourced project requires me to deal with this
interfacing to C issue, at some place or level. FLORIST
is great for some things, but if it doesn't compile on all
platforms, then you've limited your scope. If you have
things that FLORIST cannot cover (like UNIX sockets,
which are not yet supported), then you have to get down
to the bare metal or choose another library. But that
other library may have other issues (like is it easy
enough for the barely capable to compile
user to install _that_ library, before he compiles
your project), and so on.

So right now, this issue is royally painful for any
portable Ada project that must interface to the C
world.

> Rather than a binding to some C/C++ library that does 
> graphics - why not an *Ada* library that does graphics? (More work, 
> clearly, but it provides a chance to *innovate* and do something that 
> might provide a good reason to go with Ada.)

Clearly, there is a need for libraries and Graphics for Ada. No
argument there. I am glad to see the effort that is taking
place in GtkAda. But I wish we could have a better solution for
interfacing to C/C++. That would greatly lower the uphill slope
that any Ada95 enthusiast has to climb.
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg
[Remove nospam from the email address:
the worms made me do it!]