Re: Cairo Ada binding questions
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Sun, 24 Sep 2006 21:50:00 +0200
On Sun, 24 Sep 2006 18:25:14 +0200, Damien Carbonne wrote:
I have started to write an Ada binding for Cairo
(http://cairographics.org). Cairo is written in C and I know how to
write a C/Ada thin binding.
My trouble is with a thick Ada API. I will try to explain it with an
example.
Cairo has a concept of Surface class that can is specialized into PDF
Surface, SVG surface, etc. In the C API, Surfaces (as all Cairo
"classes") are always manipulated through pointers. As a Surface can be
shared, the C API provides a way to increment / decrement the reference
counter.
So, I see here two concepts : Surface and Surface Handle.
In Ada, I could have something like this :
type Surface_Record (<>) is tagged limited private;
type Surface_Ref is access all Surface_Record'Class;
The would be used that way:
procedure Foo (Surface : in [out] Surface_Record'Class; ...);
And when necessary:
procedure Bar (Surface : in Surface_Ref; ...);
or, probably better(?):
procedure Bar (Surface : access Surface_Record['Class]; ...);
However, by doing that, I let the user manage himself reference
counting. If I want to provide a Handle for ref counting, I have several
solutions based on smart pointers:
1) provide a Handle for root class of each hierarchy.
2) provide a Handle for each class of the hierarchy.
This second solution seems quite heavy to write. One needs to maintain
two parallel hierarchies, which is not really satisfying.
In both cases, smart pointers usage may also be quite uneasy, as there
is no way to make an object look like an access in Ada. At least, this
was impossible in Ada 95 (cf. Smart Pointers article by Matthew Heaney
on AdaPower).
So we would have something like this:
type Surface_Handle is private;
function Ref (Handle : Surface_Handle) return Surface_Ref;
that could be used like this :
Surface : Surface_Handle;
begin
Foo (Ref (Surface).all, ...);
or with the renaming trick to avoid this wordy thing.
There is also another solution, that would consist in hiding the Surface
concept, providing only the Surface_Handle one.
In that case, API would be modified like this :
procedure Foo (Surface : in Surface_Handle'Class; ...);
Direction would (almost ?) always be in.
From user point of view, this is far easier. From engineering point of
view, I really wonder.
This is the solution I am using. You can take a look at:
http://www.dmitry-kazakov.de/ada/components.htm
I define operations on both the objects and the handles to. The latter
delegate to the former:
package Surface is
type Surface_Object is abstract new Entity with private;
type Surface_Object_Ptr is access Surface_Object'Class;
-- Primitive operations on Surface_Object (delegatee)
procedure Foo (Surface : in out Surface_Object) is abstract;
. . .
private
type Surface_Object is abstract new Entity with ...;
package Surface_Handles is
new Object.Handle (Surface_Object, )Surface_Object_Ptr);
In a child package:
package Surface.Handle is
type Surface_Handle is [tagged] private;
-- Delegators to primitive operations on Surface_Object
procedure Foo (Surface : in out Surface_Handle);
. . .
private
type Surface_Handle is new Surface_Handles with null record;
There are drawbacks of this approach. Ada lacks any support for delegation,
so all delegators like Foo need to be written manually:
procedure Foo (Surface : in out Surface_Handle) is
begin
Foo (Ptr (Surface).all);
end Foo;
It is extremely boring. Then, there are also problems with visibility
rules, which make it difficult to hide the object types and the primitive
operations on them.
Searching a solution to this issue, I looked at Ada.Text_IO and saw that
File_Type is often passed as a in parameter when, IMO, it should not.
For example :
procedure New_Line (File : File_Type; Spacing : Positive_Count := 1);
Adding a new line modifies a file. This implies that File_Type must be
implemented with an indirection. Unless there is something I have not
understood, I don't find this really satisfying.
As with any kind of referential objects, there exists a question what
in-out applies to. I tend to use in-out for the cases you describe, because
Surface_Handles is considered a full substitute for Surface_Object.
I Think my problem is quite general and may also exist in pure Ada code.
IIRC, GtkAda adopted the very first solution: It's user responsibility
to handle memory correctly.
I found GtkAda (to be honest, Gtk+) design quite difficult to use. You
never know when and if a new object needs Unref. In the design I have
described, there is no such problem at all. All factories return handles,
instead of raw pointers. So I can happily forget about all the stuff like
reference sink vs. unref, about freeing new objects upon exceptions etc.
BTW, the behavior on exceptions is corrupt in GtkAda: I met no exception
handler in any Gtk_New, I looked. So when Initialize propagates an
exception, then the Gtk_New calling it leaks.
To summarize solutions :
1) manual memory management
1.a) Class Hierarchy and Ref (Ada Access) concepts
1.b) ???
2) automatic memory management
2.a) Class Hierarchy and Handle (Root only)
2.b) Class Hierarchy and Handle hierarchy
2.c) Handle hierarchy
2.d) ???
As I said I am using 2. Class hierarchy is IMO inevitable. Under this
condition handles hierarchy becomes difficult [almost impossible] in Ada.
In my experience, a handles hierarchy would require downcasting. But if you
allowed this, then you could do the same with one handle type as well.
Possibly, it will be easier to have independent handle types and
conversions between them rather than a hierarchy. I know, it is ugly, but
at least it works.
PS1: If a Cairo Ada binding already exists, let me know !
PS2: If this binding reaches a satisfying state and is of interest to
anyone, I will publish it.
I host a small page with GtkAda contributions:
http://www.dmitry-kazakov.de/ada/gtkada_contributions.htm
Let me know when your binding will be ready.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- References:
- Cairo Ada binding questions
- From: Damien Carbonne
- Cairo Ada binding questions
- Prev by Date: ANNOUNCE: XML EZ Out 1.05 Available
- Next by Date: Re: Cairo Ada binding questions
- Previous by thread: Cairo Ada binding questions
- Next by thread: Re: Cairo Ada binding questions
- Index(es):
Relevant Pages
|
|
