On 03/08/2010 04:57 PM, Jim Bosch wrote:
Hmm, this is a good point: By compiling the numpy wrapper as part of
boost.python, we would make numpy a prerequisite for boost.python, which
isn't a good idea. So keeping it header-only may be better.
I'm still not sure what your concern is with the numpy header. Why can't
it be exposed to user code ?
I just don't like that you have to #define something before including
the header, and that it's different in the source file that calls
"import_array()" than in all the others. In fact, I find it unfortunate
that "import_array()" needs to be called at all, but I haven't found a
way around that. I'm also mildly annoyed that it doesn't #include
<Python.h> even though it requires it.
This is all just a really ugly replacement for namespaces, and it may be
necessary in C extensions, but shouldn't be necessary in a C++
extension. You should be able to just do
"#include<boost/python/numpy.hpp"
(or whatever) and have it all just work.
Right. And that's all the users of my wrapper do. Everything else
happens within my wrapper code.
Finally, I've checked in what I have so far in the sandbox:
http://svn.boost.org/svn/boost/sandbox/numpy/
Thanks, I'll have a look.
There's still a lot to do before I'd call it complete, but it has (IMO)
the most important low-level functionality. If anyone wants to toss in
a bjam-based build system, I'd much appreciate it - I don't know jam at
all.
I'm little better, but will try to clone something I know works.
Ping me in a couple of days, if you haven't heard back from me.
Thanks,
Stefan
--
...ich hab' noch einen Koffer in Berlin...
_______________________________________________
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
