Re: exporting __stdcall methods
"John Maddock" <john@johnmaddock.co.uk> writes:
Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp which are outside the Boost.Python library would need to be enhanced to deal with __stdcall, etc.
Should now be fixed in cvs: provided the changes don't break anything else of course!
Fantastic! Thanks, John! -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"John Maddock" <john@johnmaddock.co.uk> writes:
Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp which are outside the Boost.Python library would need to be enhanced to deal with __stdcall, etc.
Should now be fixed in cvs: provided the changes don't break anything else of course!
Fantastic! Thanks, John!
weee!
Hi ! as I have some time ahead, I upgraded my codebase to latest boost snapshot. I was quite surprised to see that, by default, BPL still can't export __stdcall & __fastcall functions, or, at least, I could not find anything that allows that !... I thought that it may be useful to send my patch to deal with these calling conventions... I improved somewhat the patch I used before to handle the situation a little bit like type_traits lib does, by adding two defines that should sit in BPL config.hpp : BOOST_PYTHON_ENABLE_STDCALL and BOOST_PYTHON_ENABLE_FASTCALL. I did not go on tweaking or adding a specific test, as I first wanted to have some feedback about the usefulness of such a patch and about the quality of the one I'm proposing. Any thoughts ? Regards, Nicolas. ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: "John Maddock" <john@johnmaddock.co.uk> Cc: "pysig" <c++-sig@python.org> Sent: Thursday, March 17, 2005 4:48 PM Subject: [C++-sig] Re: exporting __stdcall methods
"John Maddock" <john@johnmaddock.co.uk> writes:
Files like boost/type_traits/detail/is_mem_fun_pointer_tester.hpp which are outside the Boost.Python library would need to be enhanced to deal with __stdcall, etc.
Should now be fixed in cvs: provided the changes don't break anything else of course!
Fantastic! Thanks, John!
-- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ C++-sig mailing list C++-sig@python.org http://mail.python.org/mailman/listinfo/c++-sig
"Nicolas Lelong" <nico_ml@mgdesign.org> writes:
Hi !
as I have some time ahead, I upgraded my codebase to latest boost snapshot. I was quite surprised to see that, by default, BPL still can't export __stdcall & __fastcall functions, or, at least, I could not find anything that allows that !...
I thought that it may be useful to send my patch to deal with these calling conventions...
I improved somewhat the patch I used before to handle the situation a little bit like type_traits lib does, by adding two defines that should sit in BPL config.hpp : BOOST_PYTHON_ENABLE_STDCALL and BOOST_PYTHON_ENABLE_FASTCALL.
I did not go on tweaking or adding a specific test, as I first wanted to have some feedback about the usefulness of such a patch and about the quality of the one I'm proposing.
Any thoughts ?
Nicolas, I think it would be great to support these other calling conventions. Your patch looks good, but I'm quite surprised that it's so small. Is that really all that's required to implement full stdcall/fastcall support? P.S. Sorry this reply is so late! -- Dave Abrahams Boost Consulting www.boost-consulting.com
Hi Dave, sorry I linger in responding, I'm only getting back to business after some holidays :)
I think it would be great to support these other calling conventions.
glad you see some interest in this too!
Your patch looks good, but I'm quite surprised that it's so small. Is that really all that's required to implement full stdcall/fastcall support?
hm, as I did this some time ago already, I took some time to test it a little more. I extensively used the patch with stdcall "C" functions, but I investigated some more by tweaking the "polymorphism" test. I seems to work all right for regular functions and member functions. I noticed a "limitation" though : if a pure virtual member function is exported with a given default implementation, this default implement _must_ the same calling convention as the pure virtual function. I'm not sure that this is annoying, perhaps this can be corrected : the problem comes from the 'not_a_derived_class_member' call in 'class.hpp' (line 146 in boost 1.33 release) - see attached file 'func_sig_def_impl_fail.cpp'. I attach the tweaked 'polymorphism' files. I also added the support for __cdecl member functions, and changed the macros to enable the functionality to match more closely what is found in type traits lib, so I attach a patch for signature.hpp (not widely different from the previous one) and config.hpp. I'm open to any thoughts or directions you could give me to integrate properly this patch into BPL. Cheers, Nicolas.
"Nicolas Lelong" <nico_ml@mgdesign.org> writes:
Hi Dave,
sorry I linger in responding, I'm only getting back to business after some holidays :)
Likewise, I'm sorry too. I am not ignoring this post; it's marked "important." I am just overcommitted at the moment and have to wait for the right opportunity to get back into things. If Ralf has the time and wants to review your patch, I'm willing to trust his decisions in the matter and/or answer his questions about specific areas of concern. Regards, -- Dave Abrahams Boost Consulting www.boost-consulting.com
Likewise, I'm sorry too. I am not ignoring this post; it's marked "important." I am just overcommitted at the moment and have to wait for the right opportunity to get back into things.
That's something I fully understand :)
If Ralf has the time and wants to review your patch, I'm willing to trust his decisions in the matter and/or answer his questions about specific areas of concern.
OK, I'm still willing to support this patch and I still have some time to work on it. So let's say that if Ralf wishes to get involved, I'm open and available for comments ! Cheers, Nicolas.
--- Nicolas Lelong <nico_ml@mgdesign.org> wrote:
Likewise, I'm sorry too. I am not ignoring this post; it's marked "important." I am just overcommitted at the moment and have to wait for the right opportunity to get back into things.
That's something I fully understand :)
If Ralf has the time and wants to review your patch, I'm willing to trust his decisions in the matter and/or answer his questions about specific areas of concern.
OK, I'm still willing to support this patch and I still have some time to work on it. So let's say that if Ralf wishes to get involved, I'm open and available for comments !
I don't feel competent at all in this matter. I'd be happy to check in the patches after verifying that nothing is broken, but I am not qualified to do serious vetting of the new feature(s). Nicolas, if you send me the patched files bundled in a zip or tar file (with full path names relative to the top-level boost directory) I'll try them out locally. Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
"Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> writes:
--- Nicolas Lelong <nico_ml@mgdesign.org> wrote:
Likewise, I'm sorry too. I am not ignoring this post; it's marked "important." I am just overcommitted at the moment and have to wait for the right opportunity to get back into things.
That's something I fully understand :)
If Ralf has the time and wants to review your patch, I'm willing to trust his decisions in the matter and/or answer his questions about specific areas of concern.
OK, I'm still willing to support this patch and I still have some time to work on it. So let's say that if Ralf wishes to get involved, I'm open and available for comments !
I don't feel competent at all in this matter. I'd be happy to check in the patches after verifying that nothing is broken, but I am not qualified to do serious vetting of the new feature(s). Nicolas, if you send me the patched files bundled in a zip or tar file (with full path names relative to the top-level boost directory) I'll try them out locally. Cheers, Ralf
What ever happened with this? Did you test it, Ralf? Did we check it in? -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Leonard "paniq" Ritter -
Nicolas Lelong -
Ralf W. Grosse-Kunstleve