Hi Vincent,
Somehow, for some classes their copy constructor was exported, but their
'normal' constructors were not.
hmm; I can't say that has been a problem for us (if I understand things
correctly). If it's not too much work (since you already departed from
gccxml), do you have an explicit class that exhibits the problem?
That would be nice, because that would mean less C++ code to maintain and
users wouldn't need to go through the trouble of getting the Clang plugin
running. However, it would require me to write code to parse those files.
Yes, we don't parse the PCH ourselves either. That'd be too much. We use the
ASTs directly from clang, through clang/AST.
I've read about it in the PyPy blog, but since I didn't hear anything about
it for a long time I forgot about it.
Yes, we really need to give a status update. :} Especially since we recently
had a sprint in Dusseldorf.
It seems like we have two different goals. While cppyy purely focuses on
C++, Wrappyr tries to make the path from C or C++ to a working Python API
(compatible with any Python implementation with a working ctypes module)
as short and simple as possible.
I don't see those as differences per se: cppyy works with C as well, of
course, and the CPython implementation is already available (albeit packaged
in the ROOT class library we use here in HEP and several other places, but
ROOT is part of a handful of Linux distro's already, so it's not too hard to
get, and it is supposed to move to llvm by the Summer of next year as well).
As for easy access, yes that is the main goal. For the CPython side, we have
managed to get it down to a one-liner for end-users, either within the build
system or within the interactive environment. It doesn't get easier than
that. :} On the cppyy side, it's a work in progress, but the same techniques
apply, and the end-result should be one-liners again.
Those XML file are just helpers for working with ctypes. See:
https://github.com/ShishKabab/Wrappyr/blob/master/ctypes_builder/README.rst
That's looking nice. In our case, the same information is scattered over
several files (b/c of historic reasons and different use cases).
As for mapping C/C++ idioms to Python (like the __iter__ protocol), the
problem is that many libraries have their own way of doing things.
They do, but there are not that many different ways of doing the same thing
that are in actual use. Not even in C++. :) And it is here where a lot of the
ease-of-use can be gained, precisely since all information is available to
a parser of headers. For example, if a class has methods called begin() and
end() which return types that have dereference and increment or decrement
operators, it's clear what is going on. The same with the examples you name.
Best regards,
Wim
--
wlavrij...@lbl.gov -- +1 (510) 486 6411 -- www.lavrijsen.net
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
