On Mar 5, 2013, at 5:41 PM, Juan Jose Garcia-Ripoll
<juanjose.garciarip...@gmail.com> wrote:
> On Tue, Mar 5, 2013 at 7:15 PM, Christian Schafmeister
> <chris.sc...@verizon.net> wrote:
> 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.
>
> 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.
The boost code is awful - I completely agree - but it works. :-)
I've copied and adapted a good portion of it but not all of it.
C++ template programming is to macro-programming as Tax forms are to poetry.
>
> "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.
>
> 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.
>
> But there is a reason no one has done this (interfaced the more complicated
> language features of C++ and CL) before.
> There is also a reason why SWIG exists and why boost::python exists.
> I've taken the boost::python approach to interfacing C++ to CL - this has not
> been done before.
>
> Not that I ever heard of.
>
> Using my (boost::python-like) approach C++ classes have either single or
> multiple inheritance, the inheritance structure is duplicated in CL.
> 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.
>
> I assume that each method is exposed only once, am I wrong. I am thinking on
>
> class A {
> int method() const;
> };
>
> class B {
> int method() const;
> };
There are two ways to handle this where neither A nor B are subclasses of each
other:
Approach 1:
class_<A>()
.def("a-method",&A::method);
class_<B>()
.def("b-method",&B::method);
In CL we are used to that; there is SYMBOL-NAME and PACKAGE-NAME.
Approach 2:
I also implemented SINGLE-DISPATCH-GENERIC-FUNCTION and SINGLE-DISPATCH-METHOD
that work like simplified generic functions/methods but only dispatches on a
single argument and doesn't have before/after/around methods. I still need to
extend these to allow users to extend C++ classes with single-dispatch-methods
in CL.
Then you use:
class_<A>()
.def("method",&A::method,"((x A))");
class_<B>()
def("method",&B::method,"((x B))");
If "a" is an instance of A and "b" is an instance of B in CL the dispatcher
dispatches (method a) to A::method and (method b) to B::method.
>
> 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.
>
> Best,
>
> Juanjo
>
> --
> Instituto de Física Fundamental, CSIC
> c/ Serrano, 113b, Madrid 28006 (Spain)
> http://juanjose.garciaripoll.googlepages.com
------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the
endpoint security space. For insight on selecting the right partner to
tackle endpoint security challenges, access the full report.
http://p.sf.net/sfu/symantec-dev2dev
_______________________________________________
Ecls-list mailing list
Ecls-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ecls-list
