Re: [boost] Re: py_cpp

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-05 23:36:01

----- Original Message -----
From: "Anton Gluck" <gluc_at_[hidden]>

> > > 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 :-)

Unfortunately, the guy's email connection seems to be malfunctioning. He
sent me the code but has been unable to respond to any of my commentary. I
am going in for surgery (!) tomorrow morning, so I'm going to try to package
his changes for release tonight but I wouldn't count on anything for the
next few days. Sorry!

> > > 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

Yes, quite so. That should go into the documentation. Actually, I'd like to
find a way to package all of this as a separate DLL so that at least this
part of the source code can be shared by multiple extension modules, but I
haven't yet become expert enough in DLL stuff.

> 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(..).

Maybe we'll just stick with the 'C' library for the example ;-)

> 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.

OK.

> 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?

Well, the compiler warnings should tell you something. Either you changed
the options in the VC6 project I supplied or I somehow stripped a crucial
file which stores compiler options, because /GR- turns off RTTI and the
library *definitely* relies on the presence of RTTI! Do you know which files
store these settings?

> 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)).

That pretty much seals it!

> 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

Yes, I discovered that the method of statically allocating the
ExtensionClass<> instance doesn't actually work: Python is reference-count
based, and it doesn't pay to try to subvert that. I'll release an updated
example soon, but probably not before I release the overloading code. I
suggest looking at extclass_demo.h/cpp. It may not be simple but it's fairly
complete and better tested than the example <blush-of-embarrassment>.

> 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...

Questions are good. Fire is bad. Fire bad!

-Dave