C Meeting

[Mark S. Miller <mark>]

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 
   utility!). 

3 minor quibbles:

The mods need to be made to the "container" classes: tables & sets (&
possibly regions).

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.

   ... (actually, 
   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" 
   as necessary).

Actually, I believe our wrapper functions will do all the enrolling,
and the user will be doing all the expelling.