Thick vs. Thin bindings

Thick vs. Thin bindings

[Jeff Houck]

As I continue to evaluate Ada in the role of a game dev language, I've 
run across references to "thick" and "thin" bindings and I'm a bit 
confused.
My initial design goals are to keep the number of external dependancies 
to a minimum with most of the support code written in Ada. I would like 
the code interfaces to be as simple as possible to implement for a 
designer. I believe this would necessitate a "thick" binding. Is that 
correct? Would anyone like to elaborate on the pros and cons of these 
two binding methodologies? Further reading material? Tutorials? Thx!




--

X-Privat "FREE Usenet" - http://www.newsserver.it

Re: Thick vs. Thin bindings

[Marius Amado Alves]

Jeff Houck wrote:
> As I continue to evaluate Ada in the role of a game dev language, I've 
> run across references to "thick" and "thin" bindings and I'm a bit 
> confused.
> My initial design goals are to keep the number of external dependancies 
> to a minimum with most of the support code written in Ada. I would like 
> the code interfaces to be as simple as possible to implement for a 
> designer. I believe this would necessitate a "thick" binding. Is that 
> correct? Would anyone like to elaborate on the pros and cons of these 
> two binding methodologies? Further reading material? Tutorials? Thx!

Thick and thin are ends of a spectrum. Usually a binding is somewhere
inside the range but not exactly at one end. An Ada binding is an Ada 
unit that represents some external system. Usually the Ada unit is a 
package and the external system is a C function library. Here the thin 
extreme of the spectrum would correspond to the most one-to-one mapping 
you could make between the Ada entities and the C entities. My package 
Pgsql [1] provides a nice pedagogical example. It has three software levels:

    1. Ada package Pgsql
    2. Ada package Libpq
    3. C function library "libpq"

Unit 1 depends on 2 depends on 3. The binding 2-3 is the thinest, and 
1-3 is the thickest.

[1] Pgsql is a minimal Postgres binding available at
http://www.liacc.up.pt/~maa/files/Pgsql.zip

Re: Thick vs. Thin bindings

[Jeff Houck]

Marius Amado Alves wrote:


> 
> [1] Pgsql is a minimal Postgres binding available at
> http://www.liacc.up.pt/~maa/files/Pgsql.zip
> 


@Marius, I would like to examine your Postgre bindings but the link does 
not resolve when I click on it. 8(

--

X-Privat "FREE Usenet" - http://www.newsserver.it

Re: Thick vs. Thin bindings

[Marius Amado Alves]

Jeff Houck wrote:
> Marius Amado Alves wrote:
>>
>> [1] Pgsql is a minimal Postgres binding available at
>> http://www.liacc.up.pt/~maa/files/Pgsql.zip
> 
> @Marius, I would like to examine your Postgre bindings but the link does 
> not resolve when I click on it. 8(

In which non-Windows systems does this problem exist?

I'm happy to email the files to anyone who asks, but naturally I would 
prefer that my published files were downloadable by all systems.

Thanks.

Re: Thick vs. Thin bindings

[David Botton]

It usually means something along the lines of:

Thick = MFC
Thin = Win32 APIs

Re: Thick vs. Thin bindings

[Martin Krischik]

Jeff Houck wrote:

> As I continue to evaluate Ada in the role of a gamephilosophyge, I've
> run across references to "thick" and "thin" bindings and I'm a bit
> confused.
> My initial design goals are to keep the number of external dependancies
> to a minimum with most of the support code written in Ada. I would like
> the code interfaces to be as simple as possible to implement for a
> designer. I believe this would necessitate a "thick" binding. Is that
> correct? Would anyone like to elaborate on the pros and cons of these
> two binding methodologies? Further reading material? Tutorials? Thx!

A thin binding just translates the C calls into Ada calls but the C'ish
philosophy is still visible. One examle of C'ish philosophy is the '\0' at
the end of strings.

Example for a thin binding to memset:

   procedure memset (
      S : in Interfaces.C.void_ptr;
      C : in Interfaces.C.int;
      N : in Interfaces.C.size_t);

   pragma Import (
      Convention    => C,
      Entity        => memset,
      External_Name => "memset");

A think binding translates the philosophy of the original language to Ada as
well.

A think binding to memset could be a generic procedure (template in C++
talk):

generic
   type A_Type    is private;
   type A_Access is access all A_Type;
procedure Mem_Set    
      Value : in A_Access ;
      Fill : in Short_Short_Integer);

I usualy suggest to build a think binding on top of a thin bindung.

With Regards

Martin

-- 
mailto://krischik@users.sourceforge.net
http://www.ada.krischik.com

Re: Thick vs. Thin bindings

[tmoran]

> Would anyone like to elaborate on the pros and cons of these
> two binding methodologies? Further reading material? Tutorials? Thx!
  Section 2.1 of our TriAda paper "CLAW, a High Level, Portable, Ada 95
Binding for Microsoft Windows" at www.rrsoftware.com has some discussion
of Thin vs Thick.  I think of Thickness as like insulation or padding,
where more Thickness protects you from the sharp edges and holes, but
has different costs.

Re: Thick vs. Thin bindings

[Preben Randhol]

In article <41a746a0@x-privat.org>, Jeff Houck wrote:
>As I continue to evaluate Ada in the role of a game dev language, I've 
>run across references to "thick" and "thin" bindings and I'm a bit 
>confused.
>My initial design goals are to keep the number of external dependancies 
>to a minimum with most of the support code written in Ada. I would like 
>the code interfaces to be as simple as possible to implement for a 
>designer. I believe this would necessitate a "thick" binding. Is that 
>correct? Would anyone like to elaborate on the pros and cons of these 
>two binding methodologies? Further reading material? Tutorials? Thx!

One way of thinking is:

   Thin binding (if it is a C library) then you use only Integer type
   for more or less everything. Or you use C char arrays in stead of Ada
   strings etc...

   Thick binding you add more layer to the binding so that you can use
   the powers of Ada when you use your library. I mean you don't need to
   convert from a Integer type to your type for height/speed/distance
   for example...

Thin binding is faster to make and then you can make it more thick if
you like, but this involves API changes...

Even thicker binding is if you can do standard operations in one
procedure call in stead of 10 function/procedure calls.

I think I would have done a one-to-one binding to a C library as long as
this makes sense and used Ada types so you do any necessary conversion
in the binding.

Here is an example for GtkAda:

   function Get_Resizable
     (Window : access Gtk_Window_Record) return Boolean
   is
      function Internal (Window : System.Address) return Gboolean;
      pragma Import (C, Internal, "gtk_window_get_resizable");

   begin
      return Internal (Get_Object (Window)) /= 0;
   end Get_Resizable;

The C library returns a type Gboolean (which in fact is basically an
int) as you can see, but the binding returns an Ada boolean. This means
that the user of the library can use Ada's Boolean types without having
to convert the Gboolean/integer to boolean after every call to the
function.

This is perhaps a very thin thick binding, but it should give you an
idea. Another thing to remember is that if the original library uses a
function it sometimes is better (ex. when returning more than one value)
to use a procedure in Ada due to that you cannot have in out variables
in functions.

Preben