Using C++ and ctypes together: a vast conspiracy? ;)

[Joseph Garvin]

What is the goal of this conversation that goes above and beyond what
Boost.Python + pygccxml achieve?

I can't speak for others but the reason I was asking is because it's
nice to be able to define bindings from within python. At a minimum,
compiling bindings means a little extra complexity to address with
whatever build tools you're using.

 

[Joseph Garvin]

[Please keep the discussion on the list]

All in all, as I said, IMO it is too complicated to figure out the binary
layout of the C++ objects (without using a C++ compiler), also there are
quite some Python packages for accessing them.

Requiring that the C++ compiler used to make the dll's/so's to be the
same one Python is compiled with wouldn't be too burdensome would it?
Because then you could have it run a bunch of configure tests to
determine information exposing the layout. I don't know if everything
is testable, but you can for example (I learned this from the object
model book btw) write a C++ program that determines whether the
virtual function table is stored at the beginning or the end of an
object by comparing the address of an object with a virtual function
to the address of its first data member. If they're different, it's
because the vptr is stored there, otherwise it's on the end
(theoretically it could be in the middle but there's no reason for
compiler writers to do that). cpptypes could then use information
generated by tests like this that are run when the interpreter is
compiled.

 

[Thomas Heller]

I can't speak for others but the reason I was asking is because it's
nice to be able to define bindings from within python. At a minimum,
compiling bindings means a little extra complexity to address with
whatever build tools you're using.

AFAIU, pybindgen takes this approach. And, AFAIK, pygccxml can generate
pybindgen code.

 

[skip]

Scott> And what gave you then impression that Python is compiled with a
Scott> C++ compiler?

I don't think it's too much to expect that a C++ compiler be available for
the configure step if Python is being built in a C++ shop. The C compiler
used to build Python proper should be compatible with the C++ compiler
available to build C++ extension modules or C++ libraries dynamically linked
into Python.

If there is no C++ compiler available then the proposed layout sniffing just
wouldn't be done and either a configure error would be emitted or a run-time
exception raised if a program attempted to use that feature. (Or the
sniffing could be explicitly enabled/disabled by a configure flag.)

 

[Philip Semanchuk]

Hm, on Linux, gccxml (if its version is compatible with that of the C
++ compiler)
can probably help a lot. At runtime, no configure step needed.
Unfortunately not on Windows.

I'm not a gccxml user, but its install page has a section for Windows:
http://www.gccxml.org/HTML/Install.html


HTH
P

 

[Thomas Heller]

I'm not a gccxml user, but its install page has a section for Windows:
http://www.gccxml.org/HTML/Install.html

Yes, it runs on Windows (*). However, there are two problems:

1. gccxml refuses to parse quite some include files from the Window SDK.
That's probably not the fault of gccxml but MS using non-standard C++
constructs. (There is a workaround inside gccxml: it installs patched
Windows header files, but the patches must be created first by someone)

2. You cannot expect gccxml (which is mostly GCC inside) to use the MSVC
algorithm for C++ object layout, so unfortuately it does not help in the
most important use-case.

Thomas

(*) And there is even use for it on Windows to parse C header files and
generate ctypes wrappers, in the ctypeslib project.