Python / C++ integration

Paul F. Dubois dubois at users.sourceforge.net
Fri Feb 7 23:45:06 EST 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
don't
> let friends do C.  If I'm going to drop down, first it's going to be to
C++,
> 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.
If
> 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 mailing list