comp.lang.ada
 help / color / mirror / Atom feed
From: Stephen Leake <stephen.a.leake.1@gsfc.nasa.gov>
Subject: Re: Thin binding of C++ classes
Date: 2000/07/20
Date: 2000-07-20T17:04:45+00:00	[thread overview]
Message-ID: <u8zuwsptk.fsf@gsfc.nasa.gov> (raw)
In-Reply-To: 964084369.995740@tornado.itea.ntnu.no

Frode Tenneb� <frodet@nvg.ntnu.no> writes:

> I'm currently writing a binding to Tenet's MapLink (www.tenet.co.uk). This
> is my first atempt on writing a 'serious' binding. I have just stared and
> I'm already feeling stomped. :)
> 
> This is an example of a simpler class:
> 
> class TSLMotifSurface : public TSLDrawingSurface
> {
> public:
>       TSLMotifSurface (Display* display, Window handle, long flags = 0);
>       TSLMotifSurface (Display* display, Screen* screen, Colormap
> colormap, Pixmap handle, long flags = 0);
>       TSLMotifSurface (Display* display, TSLUNIXPrinter* printer);
>       virtual ~TSLMotifSurface();
>   protected:
> 
>   private:
> };

First note that this is C++. Ada 95 does _not_ define a standard way
of importing C++. It does define a standard way of importing C.

> I have though of using tagged types for the class representation, however,
> I came across ada.finalization which could be benifitial here. But I have
> not found any literature on this subject (though, I have just ordered an
> update of my library). What is recomended?

One solution is to export the required functions from the C++ code as
C functions, using "extern C". Then you can use the standard Ada 95 C
import stuff.

Another solution is to use GNAT, which can directly import C++ classes
as Ada tagged types. However, you probably have to use the gnu C++
compiler, and the importation is not simple. The GNAT user's guide
defines the pragmas to be used, but also specifically says they are
there to support an automatic binding generator, and not intended for
mere mortals.
 
> My atempt looks like this:
> 
> with X_Lib;
> 
> package TSL_Drawing_Surface.TSL_Motif_Surface is
> 
>    type Object is tagged private;
>    type Object_Ptr is access Object'Class;
> 
>    function TSL_Motif_Surface (Display : in X_Lib.Display_Pointer;
>                              Handle  : in X_Lib.Window_ID;
>                              Flags   : in Long_Integer := 1) return
> Object_Ptr;
> 
>    function TSL_Motif_Surface (Display  : in X_Lib.Display_Pointer;
>                              Screen   : in X_Lib.Screen_Pointer;
>                              Colormap : in X_Lib.Colormap_ID;
>                              Handle   : in X_Lib.Pixmap_ID;
>                              Flags    : in Long_Integer := 1) return
> Object_Ptr;
> 
> --  function Create (Display : in X_Lib.Display_Pointer;
> --                 Printer : in TSLUNIXPrinter_Pointer) return Object_Ptr;
> 
> private
>    pragma Import (C, TSL_Motif_Surface, "TSLMotifSurface");
>    type Object is tagged with null record;
> 
> end TSL_Drawing_Surface.TSL_Motif_Surface;
> 
> However, trying to 
> 
> (15)   Ds       : TSL_Drawing_Surface.TSL_Motif_Surface.Object_Ptr;
> (23)   Ds := TSL_Drawing_Surface.TSL_Motif_Surface.TSL_Motif_Surface 
>          ( Display => Display,
>            Handle  => X_Toolkit.XtWindow( toplevel ),
>            Flags   => TSL_DOUBLE_BUFFERING);
> 
> gives:
> 
> example.adb:15:52: "Object_Ptr" not declared in "TSL_Motif_Surface"
> example.adb:23:47: "TSL_Motif_Surface" not declared in "TSL_Motif_Surface"
> gnatmake: "example.adb" compilation error

You'll have to provide the exact code you compiled; obviously
"Object_Ptr" is declared in TSL_Motif_Surface, so you've probably got
a bad "with" clause or something.

> Then there is the case with the overloaded constructor. Will pragma Import 
> handle this accordingly? Should I go for a thicker binding?

Pragma Import does not support importing any C++ code, at least in the
Ada 95 standard. See above about GNAT specific solutions. You can wrap
each constructor in a uniquely-named "extern C" function, and import
that into Ada.
 
> Furthermore, the parent class of this one (TSLDrawingSurface) uses friend.
> How is that best dealt with?

By making a tree of child packages, with some private children and
some public children. Private children are somewhat like friend
classes; they can access the private parts of the parents.

-- 
-- Stephe




      reply	other threads:[~2000-07-20  0:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-20  0:00 Thin binding of C++ classes Frode Tenneb�
2000-07-20  0:00 ` Stephen Leake [this message]
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox