Python / C++ integration
Paul F. Dubois
dubois at users.sourceforge.net
Sat Feb 8 05:45:06 CET 2003
Check out the new version of SWIG at swig.org. That is what my group is
using for Python / C++.
"Brandon Van Every" <vanevery at 3DProgrammer.com> wrote in message
news:zrH0a.3359$tO2.368545 at newsread1.prod.itd.earthlink.net...
> Ok, so Numarray addresses a lot of my 3D graphics concerns.
> People have said "just drop down to C" when you want to do something
> efficient. That is not acceptable. I don't drop down to C. Friends
> let friends do C. If I'm going to drop down, first it's going to be to
> then to ASM. There are lotsa valid reasons to keep an OO paradigm before
> descending to ASM. Python cannot be "the owner" of my OO paradigms in my
> development. It may own a layer of them, but I certainly won't let it own
> all of them.
> What are the pitfalls of trying to get classes to interoperate between
> Python and C++?
> One pitfall has already come up: Python consumes more storage for basic
> types than does C++. The objects will not be the same size. This has
> implications... some mitigable... but also opening a door to tedium. I
> might write some translation layers by hand, but I won't write a bunch.
> it's about manual labor, then in practice, Python and C++ will be loosely
> coupled. Mostly off in their own worlds, really.
> How about throwing exceptions?
> How about allocation and deallocation of objects?
> How about debuggers?
> Any other gotchas?
> Cheers, www.3DProgrammer.com
> Brandon Van Every Seattle, WA
> 20% of the world is real.
> 80% is gobbledygook we make up inside our own heads.
More information about the Python-list