[PYTHON C++-SIG] Re: LLNL Python/C++ integration: current status (fwd)

[Johann Hibschman]

On Tue, 18 Feb 1997, Geoffrey Furnish wrote:

> Johann Hibschman writes:
>  > However, I would like to see enough cooperation and awareness of the
>  > compiler issue to consider containing uses of things like member function
>  > templates and RTTI code to discrete portions of the code.  Those discrete
>  > portions can then be worked around with elaborate hacks by the
>  > compiler-challenged. 
> 
> The direct invocation of C++ member functions should work with an
> compiler at the level of Cfront 2.1 or better.  I know of only one
> computer in the world where the situation is still this bad (name
> withheld to protect the guilty).

Right.  There shouldn't be any problem with that.

> However, the argument parsing in our plan uses member templates.  I
> could imagine a non-member template plan working something like this:
> 
> template<class X1, class X2>
> void PyArgs_ParseTuple( PyArgs *args, X1& x1, X2& x2 );
> 
> You would then do something like:
> 
> PyArgs_ParseTuple( args, x1, x2 );
> 
> instead of what we will do:
> 
> args->ParseTuple( x1, x2 );
> 
> This would rely on only regular templates, not member templates, and
> would help people get through the pinch for a while.

I'd prefer to keep the programmer API the same, and find some good way to 
modify the PyArgs class to work without changing its interface.  Perhaps an 
additional class could mediate the call.

On a similar note, is the static cast in

   PyArgs *arglist = static_cast<PyArgs *>( args );

really necessary?  Couldn't the constructor PyArgs class simply take a 
PyObject pointer argument instead, like

   PyArgs *arglist = new PyArgs ( args );

or is there some reason this won't work?

- Johann

---
Johann Hibschman
johann at physics.berkeley.edu   


_______________
C++-SIG - SIG for Development of a C++ Binding to Python

send messages to: c++-sig at python.org
administrivia to: c++-sig-request at python.org
_______________