[Ecls-list] Tighter c/c++ integration, toplevel inline c/c++ code ???

[Juan Jose Garcia-Ripoll]

On Mon, May 3, 2010 at 4:56 PM, Seth Burleigh <seth at tewebs.com> wrote:

> The goal is to incorporate all the c/c++ code  into the lisp files, not
> to create a c/c++ library. As i said, tight integration. The c++ library
> should be able to call the lisp code, and the lisp code should be able
> to call the c++ code.
>

Nobody says it can not be done right now. I think right now you have two
conceptual problems.

The first one is that you are assuming that ECL's compiler knows anything
about C. It does not. It simply passes the chunks of code you write to the C
compiler.

The second one is that you want seamless integration with the C world but
the way you conceive it is not the way the C world expects it.

You have to understand the following: a C compiler needs to know what
functions exist, what types there are, etc. This is all fine when one just
writes ONE single lisp file because everything is translated into the SAME
set of C sources.

What happens if you have multiple sources comprising a C application? They
have to *share* the knowledge about the existence of functions and
datatypes. Well, this is done in the header file, which is included in the
sources via an #include and then used.

But what happens when you insist on defining all the C/C++ datatypes and
functions in the lisp files? You *STILL* need a header. You have to have
somewhere a file which declares what you are compiling. Why? Because ECL is
not able to parse that information from your arbitrary chunks of C code.
Otherwise we would be writing a C compiler ourselves.

Now the message is as follows: if you want multiple compiled lisp files to
use the same datatypes and functions, then create a common header, foo.h,
and store there the declarations of the datatypes.

>Normally one has a C/C++ library with headers ...
>
> I know this, though i dont know much more.


As you mentioned in your other email I guess it is important for you to
really learn a bit more about C/C++ if you want to interact with it.


> I guess i should rephrase my
> quesiton. How does ecl do this:
>
> The code below was created from the lisp code:
> (defun test2 ()
>  (ffi:c-inline nil nil :void "
>   CRectangle rect;
>   rect.set_values (3,4);
>   cout << \"area: \" << rect.area();"
> ))
>
> How is the below function 'used' by the ecl compiler


Again, the ECL compiler does not USE the code. It passes it to the C
compiler which in turn produces what is expected. ECL is not going to parse
your structure definitions, it is also not going to find out the C functions
you define in the file and magically export them, it does not attempt to
substitute the C compiler. So when the C compiler gets the code that ECL is
producing it needs some hints.

One way that should just work:

* Create a common header myheader.h
* In that header write all common types you are going to need and declare
the functions that are going to be defined.
* Let all your lisp files include that header using (ffi:clines "#include
\"myheader.h\"") and then, in the lisp files you wish, write the C/C+
_definitions_
* Compile and link everything together using ECL's BUILDER routine. Roughly

(compile-file "file1.lisp" :output-file "file1.o" :system-p t)
...
(compile-file "file13.lisp" :output-file "file1.o" :system-p t)

(c::build-fasl "myfasl" :lisp-files '("file1.o" ... "file13.o"))

[ there may be typos above ]

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20100503/0f7ee4be/attachment.html>