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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b29ea596843b99f5 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Received: by 10.68.74.201 with SMTP id w9mr19257423pbv.0.1332766186969; Mon, 26 Mar 2012 05:49:46 -0700 (PDT) Path: z9ni3678pbe.0!nntp.google.com!news2.google.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Marc C Newsgroups: comp.lang.ada Subject: Re: help bridging C and Ada Date: Mon, 26 Mar 2012 05:49:32 -0700 (PDT) Organization: http://groups.google.com Message-ID: <1909024.5.1332766172831.JavaMail.geo-discussion-forums@vbbp15> References: NNTP-Posting-Host: 134.223.116.201 Mime-Version: 1.0 X-Trace: posting.google.com 1332766182 8734 127.0.0.1 (26 Mar 2012 12:49:42 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 26 Mar 2012 12:49:42 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=134.223.116.201; posting-account=mjE6MAoAAADjsB3NIuKgfHO4u-Elh3cb User-Agent: G2/1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Date: 2012-03-26T05:49:32-07:00 List-Id: On Monday, March 26, 2012 5:03:37 AM UTC-5, Brian Drummond wrote: > This partly amounts to writing your own binding, as Simon suggested. > The other part is to create a package with Ada procedures and functions= =20 > to interface to gstreamer, and use ONLY those functions everywhere else= =20 > in your code. Then only that package needs to interface to the C code. My approach to writing bindings has gotten quite minimalist and application= -specific in recent years. Unless the project itself is developing the bin= ding to a library, I create only the minimal subset of functions and data s= tructures that the app actually needs to use. I pay close attention to how the structs are being used by the C functions = and which ones I actually need to read from and write to. Between this and= exploiting C's penchant for pointers, I can dramatically reduce the amount= of binding code I need to write and verify. If some struct, say, is passed as a function argument and its purpose is to= hold some data being returned from the function, *but I don't care about a= ny of that specific data*, then I just use a type that's derived from GNAT'= s Interfaces.C.Extensions package, like Opaque_Structure_Def_Ptr. (This Ex= tensions package is GNAT-supplied, but the types are nothing more than Addr= esses and access Addresses, so one can easily roll their own.) Likewise, i= f a struct that I am binding to has some pointer fields that, again, I don'= t care about, I just use an Opaque_Structure_Def_Ptr-derived type. Granted, if I or someone else needs a more thorough binding in the future, = this binding would have to be extended. But by not writing code that I don= 't know if I'll ever need, I save the time spent writing and debugging that= , and spend it on making needed code now. Marc A. Criley