From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-24 07:50:55
----- Original Message -----
From: "Anton Gluck" <gluc_at_[hidden]>
> > To handle this case, you need to decide how you want the enum to show up
> > Python (since Python doesn't have enums). If you are satisfied with a
> > int as a way to get your enum value, you can write a simple
> > function in namespace py::
> Yes, this worked like a charm. Thanks once again!
> And here is how I show my gratitude - with yet another question :-(
> Now that I got a significant part of my DLL wrapped, I thought I'd bring
> my wrapper code up to speed with your latest examples. In particular, I
> was still using "static py::ExtensionClass", and wanted to change this to
> "py::ClassWrapper". For example I had:
> static py::ExtensionClass<CVar> CVar_class("CVar");
> which I changed to:
> py::ClassWrapper<CVar> CVar_class("CVar");
> I should also say that I have the "#include <py_cpp/class_wrapper.h>"
> line. Nonetheless, this didn't go down well. Here is the error I'm
> D:\mymodule\glue.cpp(55) : error C2664: '__thiscall py::ClassWrapper<class
> CVar,class py::HeldInstance<class CVar> >::py::ClassWrapper<class
> CVar,class py::HeldInstance<class CVar> >(const class
> py::ClassWrapper<class CVar,class py::HeldInstance<class CVar> > &)'
> : cannot convert parameter 1 from 'char ' to 'const class
> py::ClassWrapper<class CVar,class py::HeldInstance<class CVar> > &'
> Reason: cannot convert from 'char ' to 'const class
> py::ClassWrapper<class CVar,class py::HeldInstance<class CVar> >'
> No constructor could take the source type, or constructor overload
> resolution was ambiguous
> There are indeed two constructors for CVar, but they are exposed further
> down in the code without problem (when using ExtensionClass, that is).
> I guess I'm missing a piece of py_cpp somewhere. I've looked at the
> example in the documentation and the vc6_prj settings, but didn't find
> anything. Any suggestions?
It has nothing to do with CVar. The py::ClassWrapper<> constructor takes two
parameters. One should be the module object.
> I should also say that this isn't all that important right now, since I'm
> happy with the way things work with ExtensionClass (the "runtime error
> R6025 - pure virtual function call" error doesn't bother me - yet). But
> there are probably good reasons to move to the new ClassWrapper.
That would be the reason. The old static ExtensionClass idiom is just buggy.
Python expects things to be destroyed in an order corresponding to its
reference counts, not according to the C++ rules for destruction of local
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk