Re: py_cpp

From: Anton Gluck (gluc_at_[hidden])
Date: 2000-10-05 22:59:14

Dave,

> > The workaround for overloaded methods will do for now, but overloaded
> > constructors are a prominent feature of our code too. Well, let's wait and
> > see.
> 
> Honestly, I was just reviewing the code for handling these last night. You
> will probably have a solution today. :-)

Excellent! (Although today has already turned into tomorrow :-)

> I can assure you, it's true! A template itself generates no code unless it
> is instantiated roughly meaning "is used with some definite set of
> arguments". Sometimes the arguments are "deduced" based on function argument
> matching, or by being specified from within another template, but in the end
> it all comes down to types specified by the user.

Not to worry - I trust you completely! I've also confirmed that all the
templates that are being used in our library are instances of standard
library templates.

> > So now that I have the demo module (from vc6_prj) I tried test_exclass.py
> > again. But now I get this error: 'python.exe - Application Error. The
> > instruction at "[some address]" referenced memory at "[some address]". The
> > memory could not be "written".' The MSVC debugger tells me that this here
> > is the problem: 'Unhandled exception in python.exe: [some address]: access
> > violation'. Any idea what the problem here is?
> 
> probably that you need to use the --broken-auto-ptr option when you run the

Yes, that fixed it.

> test. You can find an explanation for this in test_extclass.py. BTW, also
> run the test with the -v option or it will be *really* boring when
> everything works ;)

Very true; plus, I wouldn't have wanted to miss the notification that I
(yes, I take this personally) have now passed 70 tests :-)

> > About your example1.cpp file: I've been able to compile it alright, but
> > I'm getting a lot of linker errors like this: 'example2.obj : error
> > LNK2001: unresolved external symbol "void __cdecl
> > py::handle_exception(void)" (?handle_exception_at_py@@YAXXZ)'. I've checked
> > for the /Tp option and the presence of extern "C" that are mentioned in
> > the MSDN library, but these seem ok. Any suggestions here?
> 
> You need to compile the .cpp source files into your .DLL. In particular, the
> one called py.cpp is missing in this case.

True again. Perhaps it's useful for future reference that I have (it is
necessary to?) included these py_cpp source files (I went with the
non-debug versions; more on this below):
        extclass.cpp
        functions.cpp
        init_function.cpp
        module.cpp
        newtypes.cpp
        objects.cpp
        py.cpp
        subclass.cpp

Another tip for those who stick with MSVC 6.0's standard library (which
has a broken string module): In the example, change "#include
<cstring>" to "#include <string.h>" and then delete the std:: qualifier
before strlen(..). 

I would also suggest here that you change the sample code from your web
site to the one you sent me (example1.cpp) since I could not get the code
from the web to compile unless I basically turned it into the code you
sent me.

That said, I want to mention that I got these three warnings during
compilation: 

d:\py_cpp\extclass.h(71) : warning C4541: 'dynamic_cast' used on
polymorphic type 'class py::InstanceHolderBase' with /GR-; unpredictable
behavior may result
        d:\py_cpp\extclass.h(64) : while compiling class-template member
function 'class hello::world *__cdecl 
py::PyExtensionClassConvertersBase<class hello::world>::from_python(struct
_object *,struct py::Type<class hello::world *>)' extclass.cpp
d:\py_cpp\extclass.cpp(32) : warning C4541: 'typeid' used on polymorphic
type 'class py::InstanceHolderBase' with /GR-; unpredictable behavior may
result
d:\py_cpp\extclass.cpp(32) : warning C4541: 'typeid' used on polymorphic
type 'class py::InstanceHolderBase' with /GR-; unpredictable behavior may
result

I could then import the resulting library into Python, but didn't get much
further. I could do "hi_world = hello.world(3)", but could not call any
method of hi_world. This is what happens if I try "hi_world.get()":  
"Debug Assertion Failed! Program: D:\python\python.exe File: dbgheap.c
Line: 1017 Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse) bla bla". 
And then Python gives a "RuntimeError: unidentifiable C++
exception". Originally I thought this might be because I used the
non-debug source files, but when I rebuilt the example with the .._d files
I had the same problem. Any suggestions? 

Another detail here because I just tried this: Before I had been building
debug versions, and so I now tried a release build. I don't get the above
failed assert any more, but I do get a 
        Traceback (innermost last):
          File "<stdin>", line 1, in ?
        RuntimeError: Access violation - no RTTI data!
message (when I try hi_world.get() and also hello.length(hi_world)).

Yet another detail: When I quit Python after this, I get this message:
        Runtime Error!
        Program: D:\python\python.exe
        R6025
        - pure virtual funtion call

I'm sorry for having all these questions, but perhaps it helps you to iron
out py_cpp for its release. Novices like myself would surely love to have
an easy example with good instructions...

Many thanks once again,

Toni