[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <bobp>
- Subject: C Meeting
- From: Mark S. Miller <mark>
- Date: Tue, 5 Dec 89 23:08:48 PST
- Cc: <xanatech>, <bobp>, <joel>
- In-reply-to: <Bob>,08 PST <8912052128.AA04864@xanadu>
Abstract: Just some minor quibbles with BobP's summary.
Date: Tue, 5 Dec 89 13:28:08 PST
From: bobp (Bob Perez)
After some discussion we discovered that with a few relatively
minor modifications to our table classes we could use stubble
to generate a set of C wrapper functions implementing the procedural
interfaces (once again, stubble demonstrates its tremendous general
3 minor quibbles:
The mods need to be made to the "container" classes: tables & sets (&
These mods are orthogonal from the job of doing Ceran. We need to do
these mods to make our interface more palatable to C programmers by
better supporting conversion between raw data and our container
classes. We should do this in C++ anyway, and let Ceran translate the
result. As you point out, this is a useful thing to do to our code
anyway. However, it is not necessary for a Ceran translation of our
interfaces--Ceran simply makes whatever our interface is callable from
C, while the mods simply make our interface more sensible to someone
who wants to manipulate raw data structures, even if they're in C++.
Stubble wouldn't be the tool that Ceran is implemented in. Both
Stubble & Ceran are [to be] implemented in Formic.
Generated C wrappers implement exception handling by assuming
the existence of a function called "Error_Happened", the implementation
of which is left to individual developers using their own C libraries.
"Error_Happened" gets passed a data type "Problem" (describing
the exception) in the body of the wrapper's "catch" function
prior to the return. (Note: I'm going from memory now without
benefit of notes or videotape and so I'm sure that I've libelously
mispresented the true nature of the mechanism, in which case
someone will chime in :-).
Chime. You have in fact libelously misrepresented the accuracy of
your description--it is in fact correct :-)
As new ptrs are allocated to the C programmer they are "enrolled"
in the table ... (I guess this
applies only to SPTRs?)
Good point. This had not occured to us during the meeting, but is
possibly an important optimization. If a routine is declared as
returning a wimply pointer then the routine must know the object to be
non-garbage independent of whether the caller holds on to the pointer
or not. In this case, the wrapper function that Ceran generates
should in fact *not* enroll the object. Neat.
it's even simpler because we'll probably handle most of the "enroll"
calls explicitly in our wrapper functions prior to handing back
the ptr, and leave it to the developer only to explicitly "expel"
Actually, I believe our wrapper functions will do all the enrolling,
and the user will be doing all the expelling.