Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-10-05 07:56:51


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

> Dave,
>
> So here's my detailed reply:
>
> > Anyway, I'd be glad to help. What I ask in return is that you join the
boost
> > mailing list, at least for the upcoming formal review period, and make
> > review commentary to help me improve the library.
>
> I've already subscribed. Should we continue our discussion there?

Sure, that would be great. I've forwarded this message on to the group.

> > > Or perhaps python isn't the way to go to start with?
> >
> > Oh, don't say that! Python's the right tool for everything<0.2wink>!
>
> A man skillful with Python will find that any problem requires Python for
> its solution :-)

I hope this is more than just a case of "if all you have is a hammer..." ;-)

> > I guess there's no easy workaround for overloaded constructors, but as I
> > said you'll have those in a few days.
>
> 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. :-)

> > > templates
> > > Will py_cpp handle these?
> >
> > A common question; I will be putting the answer in a FAQ in the docs:
> >
> > Yes. If you look at the examples in extclass_demo.cpp you'll see that I
have
> > exposed several template instantiations (e.g. std::pair<int,int>) in
Python.
> > Keep in mind, however, that you can only expose a template
instantiation,
> > not a template. In other words, MyTemplate<Foo> can be exposed.
MyTemplate
> > itself cannot.
>
> This will probably be fine. As far as I know only instances of templates
> from the standard library are being used, mostly vector.

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.

> > What you *can* do (if your compiler supports partial ordering of
function
> > templates - MSVC is broken and does not) is to write appropriate
> > from_python() and to_python() functions for converting a whole class of
> > template instantiations to/from Python. That won't let you create an
> > instance of MyTemplate<SomePythonType> from Python, but it will let you
> > pass/return arbitrary MyTemplate<SomeCplusplusType> instances to/from
your
> > wrapped C++ functions.
> >
> > template <class T>
> > MyTemplate<T> from_python(PyObject* x, py::Type<MyTemplate<T> >)
> > {
> > // code to convert x into a MyTemplate<T>... that part is up to you
> > }
> >
> > template <class T>
> > PyObject* from_python(const MyTemplate<T>&)
> > {
> > // code to convert MyTemplate<T> into a PyObject*... that part is up
to
> > you
> > }
> >
> > For example, you could use this to convert Python lists to/from
> > std::vector<T> automatically.
> >
> > Hope this answer doesn't scare you off ;-)
>
> Actually, this to_python and from_python stuff makes good sense, but I
> wouldn't mind not having to do this...

Just to be clear: normally, it is not neccessary (as you'll see from my
examples), except in "corner cases". Usually, you just declare a
py::ExtensionClass<MyClass> or py::ExtensionClass<MyTemplate<MyType> > ...

<snip>
> 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
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 ;)

> > > I also had troubles following your simple example - I suppose I need
to
> > > put the code you provided into two separate .cpp files, and use MSVC++
to
> > > create a DLL with them?
> >
> > Why use separate files? Where are you thinking of splitting them? I've
> > enclosed a source file for the example which you can build into a single
> > DLL.
>
> I figured the split would be "stand-alone C++" (e. g. the library I
> got) and "code for wrapping". Otherwise, how would one leave the C++ code
> untouched? (Well, the code itself wouldn't change, but it would be
> appended by the py_cpp code; or am I lost again?)

Ah, yes. That sort of separation is fine; it's the right approach for
anything bigger than a toy example.

> > > When I tried this I keep getting complaints about
> > > std::strlen() ('strlen' : is not a member of 'std'), no matter what
> > > #include I use (string, cstring, etc.).
> >
> > That's because the C++ standard library which ships with VC6 is broken.
VC6
> > users should just remove the std::qualification or update their libs
> > (www.stlport.org provides a free conforming library).
>
> Ok, I got that fixed. Thanks!

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

> > I hope this has been helpful,
>
> Absolutely! But I'm afraid that I'll be bothering you for a while yet...

No bother.
-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk