From: Jeff
Subject: C++ to Lisp FFI
Date: 
Message-ID: <LUmpd.96779$5K2.76014@attbi_s03>
Is there a general way to do this in a commercial Lisp package
(LispWorks or Allegro CL)? Or am I pretty much stuck writing a C
wrapper DLL to provide functionality to the C++ class objects and
methods?

Jeff M.

-- 
(a (href "http://www.retrobyte.org/"))
(a (href ···············@gmail.com"))

From: Wade Humeniuk
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <Nkppd.189388$df2.85163@edtnps89>
Jeff wrote:
> Is there a general way to do this in a commercial Lisp package
> (LispWorks or Allegro CL)? Or am I pretty much stuck writing a C
> wrapper DLL to provide functionality to the C++ class objects and
> methods?
> 

The major headache to interfacing with C++ is the non-standard
name mangling.  Different compilers use different name mangling
schemes, so one has to know which compiler built the DLL and how
to generate those mangled names in the Lisp's FFI.  It
is something to bring up with the C++ community.  I am not sure anyone
can effectively interface to C++ unless its C++.  Of course with
*time-and-effort* a Lisp library could be built to built interfaces
automatically.

Wade
From: Svein Ove Aas
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <co580d$dcc$1@services.kq.no>
Wade Humeniuk wrote:

> Jeff wrote:
>> Is there a general way to do this in a commercial Lisp package
>> (LispWorks or Allegro CL)? Or am I pretty much stuck writing a C
>> wrapper DLL to provide functionality to the C++ class objects and
>> methods?
>> 
> 
> The major headache to interfacing with C++ is the non-standard
> name mangling.  Different compilers use different name mangling
> schemes, so one has to know which compiler built the DLL and how
> to generate those mangled names in the Lisp's FFI.  It
> is something to bring up with the C++ community.  I am not sure anyone
> can effectively interface to C++ unless its C++.  Of course with
> *time-and-effort* a Lisp library could be built to built interfaces
> automatically.
> 
How, then, do C++ compilers interface to C++ DLLs without knowing in advance
which compiler was used to build it?

Clearly there must be some sort of standard somewhere... unless you're
implying that every C++ compiler has to know how to interface with every
other C++ compiler? That could get tiresome quickly.
From: Trent Buck
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <20041126061351.18a58810@harpo.marx>
Quoth Svein Ove Aas on or about 2004-11-25:
> Unless you're implying that every C++ compiler has to know how to
> interface with every other C++ compiler?

That's how it is (IIUC).  From the binutils / c++filt texinfo
documentation:

	   The C++ and Java languages provides function overloading,
	which means that you can write many functions with the same name
	(providing each takes parameters of different types).  All C++
	and Java function names are encoded into a low-level assembly
	label (this process is known as "mangling").

	`--format=FORMAT'
	     `c++filt' can decode various methods of mangling, used by
	     different compilers.  The argument to this option selects
	     which method it uses: [auto gnu lucid arm hp edg gnu-v3
	     java gnat]

That's at assembly level, so preumably linker objects (.so's and .dll's)
have the same problem.

-trent
From: Bruce Stephens
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <87653tivtc.fsf@cenderis.demon.co.uk>
Svein Ove Aas <·········@aas.no> writes:

[...]

> How, then, do C++ compilers interface to C++ DLLs without knowing in
> advance which compiler was used to build it?

To a first approximation, they don't.  I'd guess on Windows, compilers
would do whatever Visual Studio does, and it seems likely that the
same idea would apply to some other platforms (so on Solaris you'd
want to be compatible with Sun's C++ compiler).  But C++ seems complex
enough (it's not just name mangling, it's object formats and things
too) that that doesn't always happen smoothly: GNU C++ changed binary
format not long ago, and on Debian most C++ libraries have names
ending in c102 and now conflict with the libraries intended for the
older compilers.

> Clearly there must be some sort of standard somewhere... unless
> you're implying that every C++ compiler has to know how to interface
> with every other C++ compiler? That could get tiresome quickly.

There is at least one standard now, although it seems to be for
Itanium: <http://www.codesourcery.com/cxx-abi/>.  I think that's the
right link, anyway.  

That's what GNU C++ is aiming at for the appropriate platforms (which
seems to include x86; I don't know what else).  

Ah, here's something for Solaris:
<http://developers.sun.com/tools/cc/articles/CC_abi/CC_abi_content.html>.
From: Wade Humeniuk
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <2mqpd.207067$9b.35238@edtnps84>
Svein Ove Aas wrote:

> 
> How, then, do C++ compilers interface to C++ DLLs without knowing in advance
> which compiler was used to build it?

That is an interesting question.  How does gcc compile and link to
MS Visual Studio C++ libraries?

 From the Cygwin site: http://cygwin.com/faq.html
----
Can I mix objects compiled with msvc++ and gcc?

Yes, but only if you are combining C object files. MSVC C++ uses a different mangling
scheme than GNU C++, so you will have difficulties combining C++ objects.
----

There are other entries in the FAQ relaed to linking gcc to Visual Studio.


Wade

> 
> Clearly there must be some sort of standard somewhere... unless you're
> implying that every C++ compiler has to know how to interface with every
> other C++ compiler? That could get tiresome quickly.
From: Dan Muller
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <57spd.24151$Rf1.17677@newssvr19.news.prodigy.com>
Wade Humeniuk <····································@telus.net> writes:

> Svein Ove Aas wrote:
>
>> How, then, do C++ compilers interface to C++ DLLs without knowing in
>> advance
>> which compiler was used to build it?
>
> That is an interesting question.  How does gcc compile and link to
> MS Visual Studio C++ libraries?
>

Cygwin's version of gcc can use Microsoft's conventions for name
mangling, binary object organization, and virtual function calls. In
other words, on a Microsoft platform, Visual C++'s implementation
details are the de facto standard.
From: Dan Muller
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <e5spd.24150$Rf1.5081@newssvr19.news.prodigy.com>
Svein Ove Aas <·········@aas.no> writes:

> Wade Humeniuk wrote:
> How, then, do C++ compilers interface to C++ DLLs without knowing in advance
> which compiler was used to build it?
>
> Clearly there must be some sort of standard somewhere... unless you're
> implying that every C++ compiler has to know how to interface with every
> other C++ compiler? That could get tiresome quickly.

There is no widely used standard, and in the general case, you cannot
directly call from C++ code compiled by one compiler to C++ code
compiled by another compiler. And yes, this is unfortunate and tiresome.

Name mangling is not the only obstacle to binary compatibility. The
details of how objects represent and call virtual member functions can
and do vary among compilers, too.
From: David Golden
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <bXrqd.42789$Z14.18240@news.indigo.ie>
Svein Ove Aas wrote:

> Clearly there must be some sort of standard somewhere... unless you're
> implying that every C++ compiler has to know how to interface with
> every other C++ compiler? That could get tiresome quickly.


On Linux, there is a pseudostandard C++ ABI that is now adhered to by
several compilers, including gcc and intel.
http://gcc.gnu.org/gcc-3.2/c++-abi.html
http://www.codesourcery.com/cxx-abi/

That "should" make a C++ FFI for Lisp-on-Linux relatively easy.
From: anonymous coward
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <20041201100033.23c8689b.a@a.com>
On Thu, 25 Nov 2004 18:24:15 +0000
Svein Ove Aas <·········@aas.no> wrote:

> How, then, do C++ compilers interface to C++ DLLs without knowing in advance
> which compiler was used to build it?
> 
> Clearly there must be some sort of standard somewhere... unless you're
> implying that every C++ compiler has to know how to interface with every
> other C++ compiler? That could get tiresome quickly.

The assumption that a C++ compiler is able to use C++ DLLs compiled with another compiler is incorrect. If there was a common ABI, they could, but there isn't.

Once again, because it is so truly amazing, apart from the exceptional case (where the compilers used for the DLL and executable use the same mangling), C++ shared objects can't be used from a C++ program, let alone anything else.

It is a silly situation, but only tends to cause a problem when sharing a DLL, for which you can either make sure it exports a pure C interface (like GTK), or give people enough of the source so they can build it with their compiler (like QT). Only the first option has any merit as far as using the DLL from something other than C++. Anyone with any sense should avoid C++ interfaced DLLs like the plague. Which is a shame.

To be used by Lisp, or any other second party, there would need to be code to mangle names just like all the compilers, which could determin which compiler was used to generate the DLL. As you say, that would be tiresome.

dgym
From: Matthias Koeppe
Subject: Re: C++ to Lisp FFI
Date: 
Message-ID: <uw5sm6w1ysb.fsf@merkur.math.uni-magdeburg.de>
"Jeff" <·······@gmail.com> writes:

> Is there a general way to do this in a commercial Lisp package
> (LispWorks or Allegro CL)? Or am I pretty much stuck writing a C
> wrapper DLL to provide functionality to the C++ class objects and
> methods?

The SWIG system (http://www.swig.org) can automatically generate such
C wrapper functions for C++ libraries in order to import them into the
various supported language implementations (Perl, Python, several
Schemes etc.)

Unfortunately, for Allegro CL (the only CL implementation currently
supported by SWIG) the C++ wrapping has not been implemented yet, but
it should be easy to add.

-- 
Matthias Koeppe -- http://www.math.uni-magdeburg.de/~mkoeppe