John Morrison writes:
> Short version: need help beyond user's manual (preferably a mentor)
> making sense of sb-alien package so as to call C++ code from SBCL.
> Longer version: I have a big (several man-decades' worth) and wide
> (thousands of entry points) C++ source code base which I would like to
> drive from Common Lisp. It is far too big either to rewrite it or to
> write bindings by hand, and it is a moving target (several active
> developers, and several releases per year).
> I have successfully used GCCXML, XMLS, and some few lines of CL code
> to get parse trees corresponding to the original C++ code into CL.
> Most non-C++-class things are obvious, but:
Well, first of all, Alien doesn't know about C++. In fact, the C++
standard encourages C++ implementors to all use different
symbol-munging techniques, to discourabe other languages from linking
directly to C++ instead of via a C shim (or so I've been told). So,
although you certainly can get Alien to talk to C++, there's no
support for that built in.
> (1) I do not know how "smart" sb-alien's type matching is (e.g., has
> it any notion of classes, subclasses, and/or superclasses?), and
> whether I can convince it to let me call C++ superclass methods on C++
> subclasses (virtual methods or otherwise). I could not find such info
> in the manual (nor did I expect to). Obviously, I want to permit
> calls to such methods as they are permitted (encouraged) in C++.
It has a concept of subtypes, but the implementation isn't really
there. This has been a minor annoyance in work I've been doing
recently on adding Objective-C support to SBCL, so I've been thinking
of adding support for C's concept of pointer subtypes (ie, a (struct
child *) is a subtype of a (struct parent *).) But it's not much of a
priority for me.
There is absolutely no support for C++ methods in Alien. That said,
if you know how your C++ compiler munges names, and you know how it
lays out its objects, you could build this support on top of the
existing Alien system.
> (2) I do not know the magic involved in sb-alien's assurance that the
> lisp definitions of (say) structure members (e.g., their offsets)
> match the underlying C structure member definitions.
There's no magic, and there can't be, because we're talking about C
here. By runtime, the definition of the structs is gone, and you're
left with a bunch of code that "just happens" to use pointers to the
same memory consistently (or so it'd seem to an inquisitive Lisp
image). That is to say, Alien assumes you didn't lie to it -- and
there's a tool (sb-grovel) to extract this info automatically for you.
> While the C++
> source code I am using has accessors and mutators galore, I may want
> to do similar magic to make the facility generally useful for
> manipulating C++ class instances which lack accessors and mutators for
> all slots (a.k.a., instance variables).
This would be a part of a C++-support system layered on top of Alien.