From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,d1533431e7e9d2eb X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Re: Nontrivial examples of C interface with Ada Date: 2000/05/25 Message-ID: <8gjjeb$eng$1@nnrp1.deja.com>#1/1 X-Deja-AN: 627204341 References: <9ckmisoo8k0dh1gcajhdgqtqjqc3bjmb25@4ax.com> <8ghbqc$ram$1@nnrp1.deja.com> <392CC733.13BDDC84@quadruscorp.com> X-Http-Proxy: 1.0 x72.deja.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Thu May 25 16:13:18 2000 GMT X-MyDeja-Info: XMYDJUIDtedennison Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.7 [en] (WinNT; I) Date: 2000-05-25T00:00:00+00:00 List-Id: In article <392CC733.13BDDC84@quadruscorp.com>, "Marin D. Condic" 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.