On Sunday 03 October 2004 09:56 am, R. Mattes wrote:
> Hmm, just some questions.
> Do you treat c++ libs more or less the same as c object
> code? I recall (from reading the libtool manual) that c++
So far that is what I am doing...
> libs need a lot of extra "black magic" work during loading
> (calling of global constructors etc.). Do you just treat
It looks like the (load-foreign "libfoo.so") call does that. I put in
some global variables that require constructors to be called, and it
looks like they actually get called (Old School debugging printfs) as
soon as the library is loaded. I have no idea which body of code
(part of the Linux kernel dynamic loading of the library, or some
special magic within SBCL and its attendant code) makes this happen.
Hmm... I should add static member variables (i.e., class allocation)
to the test suite and verify the Right Thing happens.
> c++ objects like structures? (which might not be enough -
> your wrapper will need to call destroctor methods etc.).
Apologies, but I am just beginning to get my head around this.
GCCXML definitely produces symbols that correspond to the "in-charge"
constructors and destructors (i.e., the ones that are responsible for
initializing by calling the member variables' constructors, and for
calling their destructors), and when I call them from SBCL after the
library is loaded, and after the memory is allocated, they seem to do
the right thing (even so far as to call base class constructors,
Right now, however, I do NOT emit a function (or functions) that
combines the (make-alien ...) call with the constructor call. Issues
of substance include making unique yet sensible names for all the
different various constructor possibilities. Issues of style include
the wrapping issue (not sure how I should wrap a CLOS class around the
C++ code and map different constructors to the "make-instance" call --
this is one of the pieces of advice I hope to get from the list...).
Also, in the case of virtual classes (and/or members), GCCXML is
emitting some structure definitions about the vtable and some other
"internal" typeinfo structs in association with its emission of class
information. I haven't gotten my head around that either.
> How does your code deal with exceptions? This seems to be
> a major cause of grief even for c programmers using c++
> libs. Can your wrapper cope with non-local exits?
I have not even tried any of that yet.
(1) The body of code I'm trying to wrap (in the millions of lines
range) doesn't make use of exceptions during the "natural" course of
execution, so I have been punting on that for the moment.
(2) I was hoping to avoid having the extra step of auto-generating
additional C++ wrappers for the C++ library (specifically, I haven't
really looked at whether GCCXML is emitting the "right" offsets for
member variables in derived classes, and if it's not, then I'd need to
do that). Reason being is that the code base I'm wrapping routinely
has accessors and mutators for member variables, so I have been
punting on that for the moment.
Anyway, if I have to do a C++ code-generation step, then that would be
the place to catch all those exceptions and try and do something more
Additionally, the thing that worries me, and I know that I haven't
touched at all yet, is the fact that the code base I'm wrapping makes
heavy use of both "naked" callbacks (pass me a function pointer to
call) and callbacks via inheritance. I need to scope that out more...
I know there is some way to call into Lisp from foreign code, but I
haven't gotten there yet.
> Lots of hopefully not too disheartening questions ...
No, they are exactly spot-on.
==== John Morrison
==== MAK Technologies Inc.
==== 185 Alewife Brook Parkway, Cambridge, MA 02138
==== vox:617-876-8085 x115