[C++-sig] Wrapping a function that takes class type, such as type_info
I am using Boost 1.47
I have these class methods:
void Remove(const std::type_info &type);
void Remove(const boost::python::type_info type);
I tried wrapping them both in Boost.Python:
void (Entity::*Remove1)(const std::type_info&) = &Foo::Remove;
void (Entity::*Remove2)(const boost::python::type_info) = & Foo::Remove;
class_< Foo , boost::noncopyable, shared_ptr< Foo > >(" Foo", init<>())
...
.def("Remove", Remove1)
.def("Remove", Remove2)
...
(I just tried type_info of both namespaces to be comprehensive here...)
It'll compile and and I'll get that Remove method fine. Except I can't
seem to cram something into it when I try to actually execute the
subroutine. Say I have class Bar wrapped in Python too, and I have been
using it fine and dandy. How do I get Remove() to accept the type of Bar
as an argument?
Say:
foo = Foo()
foo.Remove(Bar)...
foo.Remove(type(Bar))...
I just can't get any love here:
Traceback (most recent call last):
File "", line 1, in
Boost.Python.ArgumentError: Python argument types in
foo.Remove(Foo, type)
did not match C++ signature:
Remove(class game::Entity {lvalue}, struct boost::python::type_info)
Remove(class game::Entity {lvalue}, class type_info)
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost.python: tss_cleanup_implemented link error windows 64 bit
Many thanks for the quick response. I think I am OK for the runtime as I am using the msvc compiler from the platform SDK. Depends.exe only picks up MSVCP90.dll and MSVCR90.dll and KERNEL32.dll. What is unusual in this package is that boost.python is being linked into the pyd file by adding all the .cpp files in distutils. It seems the link error can be suppressed by defining either: BOOST_THREAD_BUILD_DLL or BOOST_THREAD_BUILD_LIB ...but which one is better, or does it make no difference? We have already defined BOOST_ALL_NO_LIB to disable auto-linking. I guess I am really wondering what on earth is behind the tss issue and whether there is a simple test case to see if we are doing it right. Would something like a little function which creates and destroys threads show a memory leak if the tss is not right? Thanks, Jon On 20/02/2012 23:42, Niall Douglas wrote: Generally when I see that missing symbol it means mismatched C runtimes. Usually in my experience it's safe to declare that symbol as weak to make the link error go away while handling if it's present correctly. Niall On 20 Feb 2012 at 20:02, Jon Wright wrote: Hello, I have been trying to build pyopencl and pycuda on windows using the subset of boost in those packages on windows 64 bit. The problem is a link error due to missing tss_cleanup_implemented. The codes seem to run without problem if the link error is suppressed: http://thread.gmane.org/gmane.comp.python.cuda/2516 Does anyone know what the tss issue is about and whether it is likely to cause a problem? Any advice would be welcome. Many thanks, Jon ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Exposing 128-bytes aligned datatype
> Aligning to 128 bits is surely __attribute__((__aligned__(16)))? Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with natural alignment, i.e. __attribute__((aligned(128))). Thanks for comments, I will try to put it into the bugtracker. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost.python: tss_cleanup_implemented link error windows 64 bit
Are you saying that you're statically linking BPL into your PYD? If you are, you shouldn't do that. BPL should live in its own DLL, *especially* when not on Linux/FreeBSD. Niall On 21 Feb 2012 at 9:35, Jonathan WRIGHT wrote: > Many thanks for the quick response. I think I am OK for the runtime as I > am using the msvc compiler from the platform SDK. Depends.exe only picks > up MSVCP90.dll and MSVCR90.dll and KERNEL32.dll. > > What is unusual in this package is that boost.python is being linked > into the pyd file by adding all the .cpp files in distutils. It seems > the link error can be suppressed by defining either: > > BOOST_THREAD_BUILD_DLL or BOOST_THREAD_BUILD_LIB > > ...but which one is better, or does it make no difference? > We have already defined BOOST_ALL_NO_LIB to disable auto-linking. > > I guess I am really wondering what on earth is behind the tss issue and > whether there is a simple test case to see if we are doing it right. > Would something like a little function which creates and destroys > threads show a memory leak if the tss is not right? > > Thanks, > > Jon > > > On 20/02/2012 23:42, Niall Douglas wrote: > > Generally when I see that missing symbol it means mismatched C > > runtimes. Usually in my experience it's safe to declare that symbol > > as weak to make the link error go away while handling if it's present > > correctly. > > > > Niall > > > > On 20 Feb 2012 at 20:02, Jon Wright wrote: > > > >> Hello, > >> > >> I have been trying to build pyopencl and pycuda on windows using the > >> subset of boost in those packages on windows 64 bit. The problem is a > >> link error due to missing tss_cleanup_implemented. The codes seem to run > >> without problem if the link error is suppressed: > >> > >> http://thread.gmane.org/gmane.comp.python.cuda/2516 > >> > >> Does anyone know what the tss issue is about and whether it is likely to > >> cause a problem? Any advice would be welcome. > >> > >> Many thanks, > >> > >> Jon > >> ___ > >> Cplusplus-sig mailing list > >> Cplusplus-sig@python.org > >> http://mail.python.org/mailman/listinfo/cplusplus-sig > > > > > ___ > Cplusplus-sig mailing list > Cplusplus-sig@python.org > http://mail.python.org/mailman/listinfo/cplusplus-sig -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Exposing 128-bytes aligned datatype
On 21 Feb 2012 at 10:39, VáclavSmilauer wrote: > > Aligning to 128 bits is surely __attribute__((__aligned__(16)))? > > Oops, I wrote it wrong in the title, it is 128-bytes aligned, double[16] with > natural alignment, i.e. __attribute__((aligned(128))). > > Thanks for comments, I will try to put it into the bugtracker. 128 *byte* alignment? Wow. No, no compiler will support that legally as it would crap all over your stack frame. I vaguely remember that GCC caps alignment to 40 bytes due to some supported architecture's stack frame being incapable of going higher. If you're aligning to 128 bytes then you almost certainly need to revisit how your code is designed and what algorithms are being used. I can think of two occasions ever in my life where I have seen an alignment larger than 32 bytes being a reasonably good idea, and one of those was in ptmalloc2 (which masks off the bottom megabyte of bits as a very fast way of finding the segment for a pointer). And even in ptmalloc2 I am unconvinced that approach was wise due to many reasons unimportant to mention here. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost.python: tss_cleanup_implemented link error windows 64 bit
Boost python is being compiled in .obj files and then the whole lot is linked into a .pyd. Do you have some unit tests we could use to check our builds for problems? I've not understood how the dll linking requirement works. Where should the dll live and how do you then cope with other people's boost based modules, which might link to a different boost dll version? Many thanks for your help! Jon On 21/02/2012 14:49, Niall Douglas wrote: Are you saying that you're statically linking BPL into your PYD? If you are, you shouldn't do that. BPL should live in its own DLL, *especially* when not on Linux/FreeBSD. Niall On 21 Feb 2012 at 9:35, Jonathan WRIGHT wrote: Many thanks for the quick response. I think I am OK for the runtime as I am using the msvc compiler from the platform SDK. Depends.exe only picks up MSVCP90.dll and MSVCR90.dll and KERNEL32.dll. What is unusual in this package is that boost.python is being linked into the pyd file by adding all the .cpp files in distutils. It seems the link error can be suppressed by defining either: BOOST_THREAD_BUILD_DLL or BOOST_THREAD_BUILD_LIB ...but which one is better, or does it make no difference? We have already defined BOOST_ALL_NO_LIB to disable auto-linking. I guess I am really wondering what on earth is behind the tss issue and whether there is a simple test case to see if we are doing it right. Would something like a little function which creates and destroys threads show a memory leak if the tss is not right? Thanks, Jon On 20/02/2012 23:42, Niall Douglas wrote: Generally when I see that missing symbol it means mismatched C runtimes. Usually in my experience it's safe to declare that symbol as weak to make the link error go away while handling if it's present correctly. Niall On 20 Feb 2012 at 20:02, Jon Wright wrote: Hello, I have been trying to build pyopencl and pycuda on windows using the subset of boost in those packages on windows 64 bit. The problem is a link error due to missing tss_cleanup_implemented. The codes seem to run without problem if the link error is suppressed: http://thread.gmane.org/gmane.comp.python.cuda/2516 Does anyone know what the tss issue is about and whether it is likely to cause a problem? Any advice would be welcome. Many thanks, Jon ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Exposing 128-bytes aligned datatype
> 128 *byte* alignment? Wow. No, no compiler will support that legally > as it would crap all over your stack frame. I vaguely remember that > GCC caps alignment to 40 bytes due to some supported architecture's > stack frame being incapable of going higher. > If you're aligning to 128 bytes then you almost certainly need to > revisit how your code is designed and what algorithms are being used. I did not design the OpenCL standard (see http://www.khronos.org/registry/cl/api/1.2/cl_platform.h at the end, there is cl_double16). Just to assure you, those types are never ever passed on stack. That header works just fine with gcc. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] boost.python: tss_cleanup_implemented link error windows 64 bit
On 21 Feb 2012 at 16:30, Jonathan WRIGHT wrote: > Boost python is being compiled in .obj files and then the whole lot is > linked into a .pyd. > > Do you have some unit tests we could use to check our builds for > problems? I've not understood how the dll linking requirement works. > Where should the dll live and how do you then cope with other people's > boost based modules, which might link to a different boost dll version? There is plenty of information about the pros and cons and what to do in the archives of this mailing list which is google searchable. In short, static linking means BPL based python extension modules must not interact outside of python or it'll go tits up due to their type registries not knowing about one another. That means you can't have extension A and extension B working together directly, only through python. If it's working for you right now I wouldn't worry. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Exposing 128-bytes aligned datatype
On 21 Feb 2012 at 16:46, VáclavSmilauer wrote: > > 128 *byte* alignment? Wow. No, no compiler will support that legally > > as it would crap all over your stack frame. I vaguely remember that > > GCC caps alignment to 40 bytes due to some supported architecture's > > stack frame being incapable of going higher. > > If you're aligning to 128 bytes then you almost certainly need to > > revisit how your code is designed and what algorithms are being used. > > I did not design the OpenCL standard (see > http://www.khronos.org/registry/cl/api/1.2/cl_platform.h at the end, there is > cl_double16). Just to assure you, those types are never ever passed on stack. > That header works just fine with gcc. I agree that GCC/MSVC needs two alignment specifiers, one for static data alignment and another for everything else. This would be a good candidate for inclusion into the C programming language actually. I may propose it to WG14. Niall -- Technology & Consulting Services - ned Productions Limited. http://www.nedproductions.biz/. VAT reg: IE 9708311Q. Company no: 472909. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
