Patch implementing void * support
The enclosed patch adds void * support to Boost.Python by making void an opaque type. Code that uses void * "just works" with this patch with no further effort required. Also enclosed is a testcase and the docs have been modified. Ran full testsuite on msvc7.1 and msvc6 - everything works. I don't have GCC to hand ATM, but apart from maybe a missing typename specifier I can't see anything which would fault. Cheers, Niall Only in boost: bin diff -aur boost_1_33_0/boost/python/converter/registered.hpp boost/boost/python/converter/registered.hpp --- boost_1_33_0/boost/python/converter/registered.hpp 2005-05-18 02:34:36.000000000 +0100 +++ boost/boost/python/converter/registered.hpp 2005-11-06 15:18:14.000000000 +0000 @@ -77,15 +77,35 @@ } template <class T> - registration const& - registry_lookup(T&(*)()) + inline registration const& + registry_lookup2(T&(*)()) { detail::register_shared_ptr1((T*)0); return registry::lookup(type_id<T&>()); } template <class T> - registration const& registered_base<T>::converters = detail::registry_lookup((T(*)())0); + inline registration const& + registry_lookup1() + { + return registry_lookup2((T(*)())0); + } + + template <> + inline registration const& +#ifdef BOOST_NO_CV_VOID_SPECIALIZATIONS + registry_lookup1<void>() +#else + registry_lookup1<const volatile void>() +#endif + { + detail::register_shared_ptr1((void*)0); + return registry::lookup(type_id<void>()); + } + + template <class T> + registration const& registered_base<T>::converters = detail::registry_lookup1<T>(); + } }}} // namespace boost::python::converter diff -aur boost_1_33_0/boost/python/lvalue_from_pytype.hpp boost/boost/python/lvalue_from_pytype.hpp --- boost_1_33_0/boost/python/lvalue_from_pytype.hpp 2004-08-20 12:09:16.000000000 +0100 +++ boost/boost/python/lvalue_from_pytype.hpp 2005-11-06 16:53:14.000000000 +0000 @@ -15,12 +15,25 @@ namespace detail { + struct voidptrholder; // Used to indicate a void * is being extracted + + template <class T> + inline type_info extractor_type_id2() + { + return type_id<T>(); + } + template <> + inline type_info extractor_type_id2<voidptrholder>() + { + return type_id<void>(); + } + // Given a pointer-to-function of 1 parameter returning a reference // type, return the type_id of the function's return type. template <class T, class U> inline type_info extractor_type_id(T&(*)(U)) { - return type_id<T>(); + return extractor_type_id2<T>(); } // A function generator whose static execute() function is an lvalue diff -aur boost_1_33_0/boost/python/opaque_pointer_converter.hpp boost/boost/python/opaque_pointer_converter.hpp --- boost_1_33_0/boost/python/opaque_pointer_converter.hpp 2004-08-20 12:09:16.000000000 +0100 +++ boost/boost/python/opaque_pointer_converter.hpp 2005-11-06 17:16:25.000000000 +0000 @@ -15,6 +15,7 @@ # include <boost/python/detail/none.hpp> # include <boost/type_traits/remove_pointer.hpp> # include <boost/type_traits/is_pointer.hpp> +# include <boost/type_traits/is_void.hpp> // opaque_pointer_converter -- // @@ -54,6 +55,15 @@ , detail::opaque_pointer_converter_requires_a_pointer_type<Pointer> >::type ptr_type; + typedef typename ::boost::remove_pointer<ptr_type>::type noptr_type; + typedef typename mpl::if_c< + ::boost::is_void<typename noptr_type>::value, + detail::voidptrholder, + typename noptr_type + >::type fixed_type; + + typedef typename ::boost::add_reference<typename fixed_type>::type ref_type; + private: struct instance; @@ -84,10 +94,10 @@ return (result); } - static typename ::boost::remove_pointer<ptr_type>::type& + static typename ref_type execute(instance &p_) { - return *p_.x; + return *(typename fixed_type *) p_.x; } private: @@ -132,4 +142,8 @@ } \ }} # endif + +// Declare void as an opaque type for automatic void * usage +BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void) + # endif // OPAQUE_POINTER_CONVERTER_HPP_ Only in boost/libs/python/build/VisualStudio: Debug Only in boost_1_33_0/libs/python/build/VisualStudio: boost_python.dsp Only in boost_1_33_0/libs/python/build/VisualStudio: boost_python.dsw Only in boost/libs/python/build/VisualStudio: boost_python.ncb Only in boost/libs/python/build/VisualStudio: boost_python.sln Only in boost/libs/python/build/VisualStudio: boost_python.suo Only in boost/libs/python/build/VisualStudio: boost_python.vcproj Only in boost/libs/python/build: bin-stage diff -aur boost_1_33_0/libs/python/doc/v2/faq.html boost/libs/python/doc/v2/faq.html --- boost_1_33_0/libs/python/doc/v2/faq.html 2004-11-28 03:54:58.000000000 +0000 +++ boost/libs/python/doc/v2/faq.html 2005-11-06 17:17:31.000000000 +0000 @@ -67,8 +67,6 @@ >error C2064: term does not evaluate to a function taking 2 arguments</a> </dt> - <dt><a href="#voidptr">How do I handle <tt>void *</tt> conversion?</a></dt> - <dt><a href="#custom_string" >How can I automatically convert my custom string type to and from a Python string?</a></dt> @@ -694,29 +692,6 @@ <p>(The bug has been reported to Microsoft.)</p> <hr> - <h2><a name="voidptr"></a>How do I handle <tt>void *</tt> conversion?</h2> - <font size="-1"><i>Niall Douglas provides these notes:</i></font><p> - For several reasons Boost.Python does not support <tt>void *</tt> as - an argument or as a return value. However, it is possible to wrap - functions with <tt>void *</tt> arguments or return values using - thin wrappers and the <i>opaque pointer</i> facility. E.g.: - <pre>// Declare the following in each translation unit -struct void_ {}; -BOOST_PYTHON_OPAQUE_SPECIALIZED_TYPE_ID(void_); - -void *foo(int par1, void *par2); - -void_ *foo_wrapper(int par1, void_ *par2) -{ - return (void_ *) foo(par1, par2); -} -... -BOOST_PYTHON_MODULE(bar) -{ - def("foo", &foo_wrapper); -}</pre> - - <hr> <h2><a name="custom_string"></a>How can I automatically convert my custom string type to and from a Python string?</h2> <font size="-1"><i>Ralf W. Grosse-Kunstleve provides these diff -aur boost_1_33_0/libs/python/test/Jamfile boost/libs/python/test/Jamfile --- boost_1_33_0/libs/python/test/Jamfile 2005-07-07 15:00:30.000000000 +0100 +++ boost/libs/python/test/Jamfile 2005-11-06 15:28:29.000000000 +0000 @@ -151,6 +151,7 @@ [ bpl-test extract ] [ bpl-test opaque ] +[ bpl-test voidptr ] [ bpl-test pickle1 ] [ bpl-test pickle2 ] Only in boost/libs/python/test: bjam.exe Only in boost/libs/python/test: hello.txt Only in boost/libs/python/test: voidptr Only in boost/libs/python/test: voidptr.cpp Only in boost/libs/python/test: voidptr.py Only in boost/tools/build/jam_src: bin.ntx86 Only in boost/tools/build/jam_src: bootstrap Only in boost/tools/build/jam_src: builtins.obj Only in boost/tools/build/jam_src: class.obj Only in boost/tools/build/jam_src: command.obj Only in boost/tools/build/jam_src: compile.obj Only in boost/tools/build/jam_src: execnt.obj Only in boost/tools/build/jam_src: execunix.obj Only in boost/tools/build/jam_src: execvms.obj Only in boost/tools/build/jam_src: expand.obj Only in boost/tools/build/jam_src: filent.obj Only in boost/tools/build/jam_src: fileos2.obj Only in boost/tools/build/jam_src: filesys.obj Only in boost/tools/build/jam_src: fileunix.obj Only in boost/tools/build/jam_src: filevms.obj Only in boost/tools/build/jam_src: glob.obj Only in boost/tools/build/jam_src: hash.obj Only in boost/tools/build/jam_src: hcache.obj Only in boost/tools/build/jam_src: hdrmacro.obj Only in boost/tools/build/jam_src: headers.obj Only in boost/tools/build/jam_src: jam.obj Only in boost/tools/build/jam_src: jambase.obj Only in boost/tools/build/jam_src: jamgram.obj Only in boost/tools/build/jam_src: lists.obj Only in boost/tools/build/jam_src: make.obj Only in boost/tools/build/jam_src: make1.obj Only in boost/tools/build/jam_src: modules.obj Only in boost/tools/build/jam_src: native.obj Only in boost/tools/build/jam_src: newstr.obj Only in boost/tools/build/jam_src: option.obj Only in boost/tools/build/jam_src: order.obj Only in boost/tools/build/jam_src: parse.obj Only in boost/tools/build/jam_src: path.obj Only in boost/tools/build/jam_src: pathunix.obj Only in boost/tools/build/jam_src: pathvms.obj Only in boost/tools/build/jam_src: property-set.obj Only in boost/tools/build/jam_src: pwd.obj Only in boost/tools/build/jam_src: regex.obj Only in boost/tools/build/jam_src: regexp.obj Only in boost/tools/build/jam_src: rules.obj Only in boost/tools/build/jam_src: scan.obj Only in boost/tools/build/jam_src: search.obj Only in boost/tools/build/jam_src: sequence.obj Only in boost/tools/build/jam_src: set.obj Only in boost/tools/build/jam_src: strings.obj Only in boost/tools/build/jam_src: subst.obj Only in boost/tools/build/jam_src: timestamp.obj Only in boost/tools/build/jam_src: variable.obj Only in boost/tools/build/jam_src: vc70.pdb Only in boost/tools/build/jam_src: w32_getreg.obj # Copyright Niall Douglas 2005. # Distributed under the Boost Software License, Version 1.0. # (See accompanying file LICENSE_1_0.txt or copy at # http://www.boost.org/LICENSE_1_0.txt) """
from voidptr_ext import *
Check for correct conversion
use(get())
Check that None is converted to a NULL void pointer
useany(get()) 1 useany(None) 0
Check that we don't lose type information by converting NULL opaque pointers to None
assert getnull() is None useany(getnull()) 0
Check that there is no conversion from integers ...
try: use(0) ... except TypeError: pass ... else: print 'expected a TypeError'
... and from strings to opaque objects
try: use("") ... except TypeError: pass ... else: print 'expected a TypeError' """ def run(args = None): import sys import doctest
if args is not None: sys.argv = args return doctest.testmod(sys.modules.get(__name__)) if __name__ == '__main__': print "running..." import sys status = run()[0] if (status == 0): print "Done." sys.exit(status) The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptr.cpp Date: 6 Nov 2005, 17:38 Size: 892 bytes. Type: Program-source
On 11/6/05, Niall Douglas <s_sourceforge@nedprod.com> wrote:
The enclosed patch adds void * support to Boost.Python by making void an opaque type. Code that uses void * "just works" with this patch with no further effort required.
Cool. I will try your patch today on GCC. Roman Yakovenko
I wish someone can tell me in what cases this is useful. I am sure it *is* helpful but I am trying to imagine another more extensive use case. Or, is this something more useful to Python Boost itself and not users of Python Boost. On Nov 6, 2005, at 11:55 AM, Niall Douglas wrote:
The enclosed patch adds void * support to Boost.Python by making void an opaque type. Code that uses void * "just works" with this patch with no further effort required.
Also enclosed is a testcase and the docs have been modified.
Ran full testsuite on msvc7.1 and msvc6 - everything works. I don't have GCC to hand ATM, but apart from maybe a missing typename specifier I can't see anything which would fault.
Cheers, Niall
On 7 Nov 2005 at 8:54, Brian Ray wrote:
I wish someone can tell me in what cases this is useful. I am sure it *is* helpful but I am trying to imagine another more extensive use case. Or, is this something more useful to Python Boost itself and not users of Python Boost.
A lot of GUI toolkit C++ code has message handlers of the form: virtual int Widget::handle(MsgType msg, void *data) ... where MsgType specifies what *data is. For almost all cases, the python bindings will call the C++ implementation and just pass the void * unchanged. Where an override is made, you can write separate little accessor functions to restore type info to data so python can access it. This idiom is especially popular in C code too. Cheers, Niall
Attached is a slightly fixed version of the patch. When is this patch going to be applied? On 6 Nov 2005 at 17:55, Niall Douglas wrote:
The enclosed patch adds void * support to Boost.Python by making void an opaque type. Code that uses void * "just works" with this patch with no further effort required.
Also enclosed is a testcase and the docs have been modified.
Ran full testsuite on msvc7.1 and msvc6 - everything works. I don't have GCC to hand ATM, but apart from maybe a missing typename specifier I can't see anything which would fault.
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC. Cheers, Niall The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptrpatch2.diff Date: 27 Nov 2005, 10:05 Size: 4781 bytes. Type: Unknown The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptr.cpp Date: 6 Nov 2005, 17:38 Size: 892 bytes. Type: Program-source The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptr.py Date: 6 Nov 2005, 17:24 Size: 1114 bytes. Type: Unknown
On 11/27/05, Niall Douglas <s_sourceforge@nedprod.com> wrote:
Attached is a slightly fixed version of the patch. When is this patch going to be applied?
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC.
Small mistake: you don't have to declare void as an opaque type for automatic void * usage You don't need those lines ( at least on GCC 3.3 ): + +// Declare void as an opaque type for automatic void * usage +namespace boost { namespace python { + template<> + inline type_info type_id<void>(BOOST_PYTHON_EXPLICIT_TT_DEF(void)) + { + return type_info (typeid (void *)); + } + template<> + inline type_info type_id<const volatile void>( + BOOST_PYTHON_EXPLICIT_TT_DEF(const volatile void)) + { + return type_info (typeid (void *)); + } +}}
Cheers, Niall
Roman Yakovenko.
On 27 Nov 2005 at 10:08, Niall Douglas wrote:
Attached is a slightly fixed version of the patch. When is this patch going to be applied?
Any movement on getting this patch applied to CVS? Cheers, Niall
On 6 Nov 2005 at 17:55, Niall Douglas wrote:
The enclosed patch adds void * support to Boost.Python by making void an opaque type. Code that uses void * "just works" with this patch with no further effort required.
Also enclosed is a testcase and the docs have been modified.
Ran full testsuite on msvc7.1 and msvc6 - everything works. I don't have GCC to hand ATM, but apart from maybe a missing typename specifier I can't see anything which would fault.
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC.
Cheers, Niall
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 27 Nov 2005 at 10:08, Niall Douglas wrote:
Attached is a slightly fixed version of the patch. When is this patch going to be applied?
Any movement on getting this patch applied to CVS?
All the ones you've posted come with disclaimers or corrections, such as: I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC. and: You don't need those lines ( at least on GCC 3.3 ): + +// Declare void as an opaque type for automatic void * usage +namespace boost { namespace python { Please post a definitive patchset. Thanks. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 24 Jan 2006 at 10:51, David Abrahams wrote:
All the ones you've posted come with disclaimers or corrections, such as:
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC.
It was literally a case of removing some unnecessary typename keywords. It didn't take two seconds and at that time I didn't have access to Linux. I do now. Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1. Cheers, Niall The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptrpatch.diff Date: 24 Jan 2006, 20:30 Size: 4859 bytes. Type: Unknown The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptr.py Date: 24 Jan 2006, 20:15 Size: 1114 bytes. Type: Unknown The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptr.cpp Date: 24 Jan 2006, 20:15 Size: 892 bytes. Type: Program-source
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 24 Jan 2006 at 10:51, David Abrahams wrote:
All the ones you've posted come with disclaimers or corrections, such as:
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC.
It was literally a case of removing some unnecessary typename keywords. It didn't take two seconds and at that time I didn't have access to Linux. I do now.
Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
So these workarounds that are guarded by #ifdef BOOST_MSVC Are known to be needed on vc7.1 as well as vc6? What about vc8? You ought to be using BOOST_WORKAROUND here. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 24 Jan 2006 at 10:51, David Abrahams wrote:
All the ones you've posted come with disclaimers or corrections, such as:
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC.
It was literally a case of removing some unnecessary typename keywords. It didn't take two seconds and at that time I didn't have access to Linux. I do now.
Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
So these workarounds that are guarded by
#ifdef BOOST_MSVC
Are known to be needed on vc7.1 as well as vc6? What about vc8? You ought to be using BOOST_WORKAROUND here.
This really looks careless. As submitted the patch doesn't compile because there's a missing #include <boost/type_traits/broken_compiler_spec.hpp> in type_id.hpp -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
David Abrahams <dave@boost-consulting.com> writes:
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 24 Jan 2006 at 10:51, David Abrahams wrote:
All the ones you've posted come with disclaimers or corrections, such as:
I understand from Roman that I have too many typenames in there, but other than this trivial fix the patch works perfectly on GCC.
It was literally a case of removing some unnecessary typename keywords. It didn't take two seconds and at that time I didn't have access to Linux. I do now.
Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
So these workarounds that are guarded by
#ifdef BOOST_MSVC
Are known to be needed on vc7.1 as well as vc6? What about vc8? You ought to be using BOOST_WORKAROUND here.
This really looks careless. As submitted the patch doesn't compile because there's a missing
#include <boost/type_traits/broken_compiler_spec.hpp>
in type_id.hpp
And even after I add that, it breaks compilation. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 26 Jan 2006 at 12:08, David Abrahams wrote:
This really looks careless. As submitted the patch doesn't compile because there's a missing
#include <boost/type_traits/broken_compiler_spec.hpp>
in type_id.hpp
And even after I add that, it breaks compilation.
Found the reason that missing header file didn't get spotted was because I was using my own modified Boost.Python. Having applied it to a clean v1.33 of Boost.Python the compile error shows. However after addition of that line above everything (libraries, test suite) links and compiles just fine on Windows. The test for voidptr passes. I attach a new unified diff which includes the testsuite and doc changes. Can you clarify what you mean by "And even after I add that, it breaks compilation"? Are you using a v1.33 edition or a CVS edition? It's possible a CVS edition has changed something. Cheers, Niall The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptrpatch.diff Date: 26 Jan 2006, 19:56 Size: 10128 bytes. Type: Unknown
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 26 Jan 2006 at 12:08, David Abrahams wrote:
This really looks careless. As submitted the patch doesn't compile because there's a missing
#include <boost/type_traits/broken_compiler_spec.hpp>
in type_id.hpp
And even after I add that, it breaks compilation.
Found the reason that missing header file didn't get spotted was because I was using my own modified Boost.Python.
Having applied it to a clean v1.33 of Boost.Python the compile error shows. However after addition of that line above everything (libraries, test suite) links and compiles just fine on Windows. The test for voidptr passes. I attach a new unified diff which includes the testsuite and doc changes.
Can you clarify what you mean by "And even after I add that, it breaks compilation"? Are you using a v1.33 edition or a CVS edition? It's possible a CVS edition has changed something.
Your patch must pass the Boost.Python test suite against the CVS in order to be accepted. Go to libs/python/test and do bjam -sTOOLS="<whatever>" test <whatever> might look like msvc vc-7_1 gcc for example. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 26 Jan 2006 at 15:03, David Abrahams wrote:
Your patch must pass the Boost.Python test suite against the CVS in order to be accepted.
I have tried repeatedly to get Boost from CVS during the last few days. Sourceforge says it rejects access to /cvsroot/boost for user anonymous. I have other CVS repositories on sourceforge working so I give up - I hate CVS anyway, it has never worked satisfactorily for me. If someone else wants to apply the patch to CVS and submit please feel free. Otherwise this patch is dead until the next release of Boost when I'll try again. Cheers, Niall
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 26 Jan 2006 at 15:03, David Abrahams wrote:
Your patch must pass the Boost.Python test suite against the CVS in order to be accepted.
I have tried repeatedly to get Boost from CVS during the last few days. Sourceforge says it rejects access to /cvsroot/boost for user anonymous. I have other CVS repositories on sourceforge working so I give up - I hate CVS anyway, it has never worked satisfactorily for me.
If someone else wants to apply the patch to CVS and submit please feel free. Otherwise this patch is dead until the next release of Boost when I'll try again.
You can get a tarball of the current Boost CVS state at http://www.boost-consulting.com/boost.tar.bz2 -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 8 Feb 2006 at 15:38, David Abrahams wrote:
Your patch must pass the Boost.Python test suite against the CVS in order to be accepted.
I have tried repeatedly to get Boost from CVS during the last few days. Sourceforge says it rejects access to /cvsroot/boost for user anonymous. I have other CVS repositories on sourceforge working so I give up - I hate CVS anyway, it has never worked satisfactorily for me.
If someone else wants to apply the patch to CVS and submit please feel free. Otherwise this patch is dead until the next release of Boost when I'll try again.
You can get a tarball of the current Boost CVS state at http://www.boost-consulting.com/boost.tar.bz2
The attached applies cleanly to Boost CVS 06-02-09-0100 and compiles and passes the test suite on MSVC7.1 and GCC 4.0.2. Cheers, Niall The following section of this message contains a file attachment prepared for transmission using the Internet MIME message format. If you are using Pegasus Mail, or any other MIME-compliant system, you should be able to save it or view it from within your mailer. If you cannot, please ask your system administrator for assistance. ---- File information ----------- File: voidptrpatch.diff Date: 9 Feb 2006, 11:29 Size: 10126 bytes. Type: Unknown
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 8 Feb 2006 at 15:38, David Abrahams wrote:
Your patch must pass the Boost.Python test suite against the CVS in order to be accepted.
I have tried repeatedly to get Boost from CVS during the last few days. Sourceforge says it rejects access to /cvsroot/boost for user anonymous. I have other CVS repositories on sourceforge working so I give up - I hate CVS anyway, it has never worked satisfactorily for me.
If someone else wants to apply the patch to CVS and submit please feel free. Otherwise this patch is dead until the next release of Boost when I'll try again.
You can get a tarball of the current Boost CVS state at http://www.boost-consulting.com/boost.tar.bz2
The attached applies cleanly to Boost CVS 06-02-09-0100 and compiles and passes the test suite on MSVC7.1 and GCC 4.0.2.
Well, I finally got it cleaned up and working with older compilers, but now the 1.34 feature freeze is in effect. I am waiting for the release manager's permission to check in on the trunk. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 11 Feb 2006 at 16:51, David Abrahams wrote:
The attached applies cleanly to Boost CVS 06-02-09-0100 and compiles and passes the test suite on MSVC7.1 and GCC 4.0.2.
Well, I finally got it cleaned up and working with older compilers, but now the 1.34 feature freeze is in effect. I am waiting for the release manager's permission to check in on the trunk.
Thank you. Are you happy with the way I used a trampoline type to pass a void * through BPL? It seemed a bit nasty to me. If you ever do a v3 of BPL, you may want to pass everything around by pointer though I suppose this could inhibit optimisations. Cheers, Niall
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 11 Feb 2006 at 16:51, David Abrahams wrote:
The attached applies cleanly to Boost CVS 06-02-09-0100 and compiles and passes the test suite on MSVC7.1 and GCC 4.0.2.
Well, I finally got it cleaned up and working with older compilers, but now the 1.34 feature freeze is in effect. I am waiting for the release manager's permission to check in on the trunk.
Thank you.
Are you happy with the way I used a trampoline type to pass a void * through BPL?
Not really. If you look at my revised patch you'll see that it's gone.
It seemed a bit nasty to me. If you ever do a v3 of BPL, you may want to pass everything around by pointer though I suppose this could inhibit optimisations.
Not sure what you're getting at, here. My only thought was that when we do langbinding, we should probably treat pointer types separately from their pointees so that opaque pointers are less of a hack. It means a few more type converter registration records, but that seems like a small price to pay. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 11 Feb 2006 at 16:51, David Abrahams wrote:
The attached applies cleanly to Boost CVS 06-02-09-0100 and compiles and passes the test suite on MSVC7.1 and GCC 4.0.2.
Well, I finally got it cleaned up and working with older compilers, but now the 1.34 feature freeze is in effect. I am waiting for the release manager's permission to check in on the trunk.
Thank you.
Are you happy with the way I used a trampoline type to pass a void * through BPL?
Not really. If you look at my revised patch you'll see that it's gone.
It's now on the trunk. Thanks for your contribution. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 8 Feb 2006 at 15:38, David Abrahams wrote:
Your patch must pass the Boost.Python test suite against the CVS in order to be accepted.
I have tried repeatedly to get Boost from CVS during the last few days. Sourceforge says it rejects access to /cvsroot/boost for user anonymous. I have other CVS repositories on sourceforge working so I give up - I hate CVS anyway, it has never worked satisfactorily for me.
If someone else wants to apply the patch to CVS and submit please feel free. Otherwise this patch is dead until the next release of Boost when I'll try again.
You can get a tarball of the current Boost CVS state at http://www.boost-consulting.com/boost.tar.bz2
The attached applies cleanly to Boost CVS 06-02-09-0100 and compiles and passes the test suite on MSVC7.1 and GCC 4.0.2.
Well, I finally got it cleaned up and working with older compilers, but now the 1.34 feature freeze is in effect. I am waiting for the release manager's permission to check in on the trunk.
It is in CVS on the python-voidptr branch. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 26 Jan 2006 at 12:04, David Abrahams wrote:
This really looks careless. As submitted the patch doesn't compile because there's a missing
#include <boost/type_traits/broken_compiler_spec.hpp>
in type_id.hpp
I tested the patch on windows and linux by compiling my python bindings. It would appear that the bindings include necessary header files such that everything compiles okay. I'll get back to you hopefully tonight, otherwise in ten days or so. Cheers, Niall
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 26 Jan 2006 at 12:04, David Abrahams wrote:
This really looks careless. As submitted the patch doesn't compile because there's a missing
#include <boost/type_traits/broken_compiler_spec.hpp>
in type_id.hpp
I tested the patch on windows and linux by compiling my python bindings. It would appear that the bindings include necessary header files such that everything compiles okay.
I'll get back to you hopefully tonight, otherwise in ten days or so.
A patch that works is defined as one that passes the Boost.Python test suite. Make sure you test your patch in that context on all platforms you're targeting. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
A patch that works is defined as one that passes the Boost.Python test suite. Make sure you test your patch in that context on all platforms you're targeting.
How is that possible, in general ? Typically a single developer has access only to a limitted number of platforms / compilers, requiring some form of cooperation to cover all targetted platforms. Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
David Abrahams wrote:
A patch that works is defined as one that passes the Boost.Python test suite. Make sure you test your patch in that context on all platforms you're targeting.
How is that possible, in general ? Typically a single developer has access only to a limitted number of platforms / compilers, requiring some form of cooperation to cover all targetted platforms.
A developer can't very well target a platform he has no access to, can he? It's up to Niall to say what he's targeting. Of course, if the patch is too far off of the set of compilers currently supported by the library, it might not be accepted. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Stefan Seefeld <seefeld@sympatico.ca> writes:
David Abrahams wrote:
A patch that works is defined as one that passes the Boost.Python test suite. Make sure you test your patch in that context on all platforms you're targeting.
How is that possible, in general ? Typically a single developer has access only to a limitted number of platforms / compilers, requiring some form of cooperation to cover all targetted platforms.
A developer can't very well target a platform he has no access to, can he? It's up to Niall to say what he's targeting. Of course, if the patch is too far off of the set of compilers currently supported by the library, it might not be accepted.
I was thinking of a patch to boost.python (say), which the author (of the patch) only tests on a subset of platforms / compilers of the platforms / compilers the library author(s) target. I don't know the set of supported compilers for boost.python, but I'm quite sure it is more than what I have access to. Yet I might be able to submit a patch some time or another. What am I supposed to do then ? Regards, Stefan
Stefan Seefeld <seefeld@sympatico.ca> writes:
How is that possible, in general ? Typically a single developer has access only to a limitted number of platforms / compilers, requiring some form of cooperation to cover all targetted platforms.
A developer can't very well target a platform he has no access to, can he? It's up to Niall to say what he's targeting. Of course, if the patch is too far off of the set of compilers currently supported by the library, it might not be accepted.
I was thinking of a patch to boost.python (say), which the author (of the patch) only tests on a subset of platforms / compilers of the platforms / compilers the library author(s) target. I don't know the set of supported compilers for boost.python, but I'm quite sure it is more than what I have access to. Yet I might be able to submit a patch some time or another. What am I supposed to do then ?
Tell me what compilers and platforms you're targeting your patch at, and test it on all those. Re-read what I wrote. I never said the patch had to be tested on all platforms/compilers targeted by the library. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 26 Jan 2006 at 11:43, David Abrahams wrote:
Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
So these workarounds that are guarded by
#ifdef BOOST_MSVC
Are known to be needed on vc7.1 as well as vc6? What about vc8? You ought to be using BOOST_WORKAROUND here.
I copied exactly the code at the end of opaque_pointer_converter.hpp. It uses #ifdef BOOST_MSVC, so I reused exactly the same form in type_id.hpp. If opaque_pointer_converter.hpp should be different, then so should type_id.hpp. I don't know whether it should be different for msvc7.1 - whoever wrote opaque_pointer_converter.hpp is better suited to answer that question. The only reason type_id.hpp needed a separate declaration is because GCC complained about adding template specialisations after they have been instanced. It's probably a good thing. Cheers, Niall
"Niall Douglas" <s_sourceforge@nedprod.com> writes:
On 26 Jan 2006 at 11:43, David Abrahams wrote:
Anyway, it's attached working on GCC 4.0.2 and MSVC 6.0 and 7.1.
So these workarounds that are guarded by
#ifdef BOOST_MSVC
Are known to be needed on vc7.1 as well as vc6? What about vc8? You ought to be using BOOST_WORKAROUND here.
I copied exactly the code at the end of opaque_pointer_converter.hpp. It uses #ifdef BOOST_MSVC, so I reused exactly the same form in type_id.hpp.
I didn't write that code; I probably should never have approved it in that form.
If opaque_pointer_converter.hpp should be different, then so should type_id.hpp.
Sure.
I don't know whether it should be different for msvc7.1 - whoever wrote opaque_pointer_converter.hpp is better suited to answer that question.
The only reason type_id.hpp needed a separate declaration is because GCC complained about adding template specialisations after they have been instanced. It's probably a good thing.
Hyah. But give me a patch that works, please. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (5)
-
Brian Ray -
David Abrahams -
Niall Douglas -
Roman Yakovenko -
Stefan Seefeld