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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,1563af5c167aacf2 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-06-20 07:12:37 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: dennison@telepath.com (Ted Dennison) Newsgroups: comp.lang.ada Subject: Re: thick? thin? binding Date: 20 Jun 2002 07:12:35 -0700 Organization: http://groups.google.com/ Message-ID: <4519e058.0206200612.5ab7906b@posting.google.com> References: NNTP-Posting-Host: 65.115.221.98 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1024582356 7362 127.0.0.1 (20 Jun 2002 14:12:36 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 20 Jun 2002 14:12:36 GMT Xref: archiver1.google.com comp.lang.ada:26484 Date: 2002-06-20T14:12:36+00:00 List-Id: Immanuel Scholz wrote in message news:... > I read through 1 and a half Ada book and still doesnt catch what "thick" or > "thin" binding mean... I know "flat" binding from C or "name mangling" from A thin binding to a C library would be a package spec that contains a bunch of subprograms that are "pragma interface"ed directly to the C (or STDCALL or whatever) routines. Their parameters must be set up so that C can process them correctly (strings must end with a null character, etc.) Typically the names of the routines would be exactly the same as the C routines, and you could just use the C documentation. A thick binding to a C library would present an interface of Ada routines that take Ada-style data (no pointers, strings where every character is valid and there is no terminiating null character, etc). Typically they will also be much higher-level than the C facilities, abstracting away much of the cruft (and perhaps some of the functionality). The names of the subprograms may not bear much relation to the C routine(s) they call, so a thick binding needs its own documentation. I usually try to operate in a middle ground ("semi-thick"), where each C routine has a corresponding Ada routine whose job is to translate Ada types and idoms into C types and idoms (and visa versa), and to call the C routine. That way you don't loose functionality, but you don't infect your Ada code with C stuff either. You still don't need any new documentation for such a binding, as long as you comment what C routines are called by what Ada routines.