TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Rich Pinkall-Pollei <[log in to unmask]>
Reply To:
Fri, 10 Sep 1999 11:22:25 -0500
text/plain (35 lines)
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.

Rich Pinkall-Pollei
A language that doesn't affect the way you think about programming is
not worth knowing.