<div dir="ltr">On Tue, Mar 5, 2013 at 7:15 PM, Christian Schafmeister <span dir="ltr"><<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>C++ template programming is not pretty but using template programming hands the problem of identifying C++ types and parsing C++ code to the C++ compiler where it is done properly. The other approach is to create something like SWIG, which attempts to parse C (it does a good job) and C++ (it does a lousy job) and then generate interface code.<br>

</div></div></blockquote><div><br></div><div style>I did not mean to complain about the template approach in general, but I just read the Boost code and it is awful. Sure, recursive file inclusion is neat, but it is unreadable, as much as the rest of the code. The idea of automatic coercion from various types to Common Lisp and back, though, is neat.</div>

<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>"Can be ported" - certainly. These are Turing complete languages and we can do anything computable within them. It's a question of how much time porting requires.  </div>

</div></blockquote><div><br></div><div style>Not much, I would believe. All common lisp have one or more functions to allocate foreign objects; surely they also do have functions for defining functions to be called or, if not, they can be implemented in two lines of CFFI. One can implement the template approach with a lot of boilerplate and a hundred lines of backend, I believe.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>But there is a reason no one has done this (interfaced the more complicated language features of C++ and CL) before.<br>

</div><div>There is also a reason why SWIG exists and why boost::python exists.</div><div>I've taken the boost::python approach to interfacing C++ to CL - this has not been done before.</div></div></blockquote><div><br>

</div><div style>Not that I ever heard of.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>Using my (boost::python-like) approach C++ classes have either single or multiple inheritance, the inheritance structure is duplicated in CL.<br>

</div><div>Methods are exposed once with one name, in the lowest level class that implements them and they are inherited by every class that derives from that class.</div></div></blockquote><div><br></div><div style>I assume that each method is exposed only once, am I wrong. I am thinking on</div>

<div style><br></div><div style>class A {</div><div style>  int method() const;</div><div style>};</div><div style><br></div><div style>class B {</div><div style>  int method() const;</div><div style>};</div><div style><br>

</div><div style>How do you handle this? I know the phython approach relies on the overloading that is inherent to Python's object system, but in Common Lisp it gets tricky unless you resort to CLOS.</div><div><br></div>

<div style>Best,</div><div style><br></div><div style>Juanjo</div></div><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a>
</div></div>