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