Fri, 10 Sep 1999 11:22:25 -0500
Your message of "Thu, 09 Sep 1999 10:35:01 EDT."
I use c2ada on an i586 RedHat Linux 6.0 system with the GNu Ada
Translator (gnat). The primary trouble I had getting it to work is
that most C libraries have complex and very deeply nested #includes.
To the around this, I create a short C code fragment that #includes
the necessary files and redeclare the types and functions I'm
interested in, then preprocess it using the standard C preprocessor
only. Then I run the preprocessed file through c2ada to create the
rough first cut of my binding.
I only find this process necessary for very complex calls as a means
of understanding the underlying types and calling sequences. For many
basic calls, I simply declare subtypes and subprograms using the Annex
A Interfaces.C packages. Generally, I try to limit such declarations
to the private part of a small number of packages, preferably one, and
define public subprograms and subtypes that may be used with more
conventional Ada constructs (thick binding). This localizes any
modifications required by C library changes. As long as I understand
the underlying structure of the C types, this takes very little
effort, especially since I only import what I need. I keep these
bindings in a separate library and add to them as necessary, reusing
existing definitions whenever possible.
This actually brings up a quality of design and programming advocacy
issue: creating these bindings requires a thorough knowledge of how C
does things. A lot of poorly designed C code is written by C
programmers who do not take time to learn this. From this I would
conclude that any Ada programmer with experience creating C bindings
would tend to write better C code than most C programmers.
A language that doesn't affect the way you think about programming is
not worth knowing.