Re: Nontrivial examples of C interface with Ada

[Ted Dennison <dennison@telepath.com>]

In article <392CC733.13BDDC84@quadruscorp.com>,
  "Marin D. Condic" <mcondic-nospam@quadruscorp.com> wrote:
> Ted Dennison wrote:
> pointers to everything, use normal Ada strings, enumeration types for
> return codes, etc. Of course you quite often run into cases where the

Often you can get rid of return codes altogether by using exceptions.
This works particularly well with the ever-popular "null pointer means
error" interface, and even better with the "a negative value means
error" interface.

> normal C way to do things is with a function and you have to make it
> into a procedure in order to have it make proper sense in Ada, so you

But somtimes you can go the other way. I often turn what was basicly
a "procedure with return error code" interface into a "function that
raises exception on error" interface.

Its funny how a mid-thick binding with exceptions can make a C library
routine easier to use in Ada than C. :-)

> One problem area I have found is with the use in C of error codes &
> flags. The usual C method is to declare a long list of constants -
> sometimes where the specific bits in the constants have particular
> meanings (intended to be or'ed together). You would prefer enumerated

> doesn't simply degenerate to an ugly C-ism. Maybe it would be useful
> to develop a set of guidelines as to how to do these sorts of
> translations? I certainly end up stumped sometimes as to what is the
> best choice and some consistent guidelines would be handy.

Hmm. There are of course some really weird interfaces out there,
particularly when you get into low-level OS calls. But I generally try
to stick to the rule that I use enumerations for #define'ed code sets
that are mutually exclusive (share significant bits) and packed boolean
arrays indexed by enumerations for code sets that don't. If there aren't
a lot of options, sometimes its just easier to make individual boolean
parameters for the options.

I don't think you are going to find consistent guidelines in this area
though, because a lot of this is highly contraversial. For instance,
some people don't like packed boolean arrays because the ordering of the
bits is implementation defined.

For me, the really tricky ones are the routines that return a pointer to
an object whose type is specified by the return value of another
parameter. As near as I can tell, you have to either make a separate
subprogram for each type and force the user to know what type he's
receiving when he makes the call, or you just throw up your hands and
return an address.


--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.