From qinlj at solidshare.com Fri Aug 1 01:53:44 2003 From: qinlj at solidshare.com (Lijun Qin) Date: Thu, 31 Jul 2003 16:53:44 -0700 Subject: [C++-sig] Automatic PyUnicode to 'const char*' Message-ID: <000d01c357be$feffb700$0200a8c0@barrack> Hi all, I'm using boost.python to wrap the WTL (Windows Template Libaray), using VC 7.1 and porting some old code previously use win32ui.pyd. Basically it is easy to do, though gccxml failed to parse the ATL/WTL code so I can not use Pyste. But there is a trouble, does anybody know how to automaticly convert PyUnicode to 'const char *'? Without this, I have to change lot of code lines to explictly use str() function. Lijun Qin http://www.solidshare.com From qinlj at solidshare.com Sat Aug 2 02:10:30 2003 From: qinlj at solidshare.com (Lijun Qin) Date: Fri, 1 Aug 2003 17:10:30 -0700 Subject: [C++-sig] Re: Automatic PyUnicode to 'const char*' References: <20030731174424.7728.63710.Mailman@mail.python.org> Message-ID: <005001c3588a$805b8b00$0200a8c0@barrack> > To: c++-sig at python.org > From: David Abrahams > Date: Thu, 31 Jul 2003 12:18:34 -0400 > Subject: [C++-sig] Re: Automatic PyUnicode to 'const char*' > Reply-To: c++-sig at python.org > > Stefan Seefeld writes: > > > David Abrahams wrote: > >> "Lijun Qin" writes: > >> > >>>Hi all, > >>> > >>>I'm using boost.python to wrap the WTL (Windows Template Libaray), using VC > >>>7.1 and porting some old code previously use win32ui.pyd. > >>>Basically it is easy to do, though gccxml failed to parse the ATL/WTL code > >>>so I can not use Pyste. > >>>But there is a trouble, does anybody know how to automaticly convert > >>>PyUnicode to 'const char *'? Without this, I have to change lot of code > >>>lines to explictly use str() function. > >> I'm not an expert in it, but I thought Unicode used 16- or 32- byte > >> wchar_t characters. How would you convert it to char const*? > > > > unicode allows different encodings, some (such as utf-8) with variably > > sized character representations. This means that conversions usually > > can't be done on-the-fly without helper constructs, i.e. some memory > > management is needed. > > > > As an example, I'm doing such conversions in a xml library. The C > > implementation uses 'xmlChar *', which is just an alias for 'char *', > > but really holds utf-8 encoded text. > > I convert it to various string types (the public API is parametrized > > for the string type): > > To do that kind of narrowing, at the moment, the only way would be to > write a thin wrapper function: > > void f(char const*); > > void f_thin_wrapper(object unicode) > { > str narrowed(unicode); > f(extract(str)); > } > > we may have some support for doing this automatically in the version > of Boost.Python which integrates with Luabind, but that's a ways off > yet. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > Hi, all: I have found a method to do this, by register a convert function: inline void* convert_to_cstring_from_unicode(PyObject* obj) { if (!PyUnicode_Check(obj)) return 0; PyObject* str = PyUnicode_AsEncodedString(obj, "mbcs", NULL); if (!str) throw_error_already_set(); //We must release the str before we return to python, gard here static leak_gard _gard; unicode_str_map[obj] = str; return PyString_AsString(str); } converter::registry::insert(convert_to_cstring_from_unicode, type_id()); But the problem is that the PyString object must be freed when the call is completed, I currently do this by applying a custom call policy to the methods using 'const char*' type of parameters, but if there were reclusive calls into the same fuction, it'll much complex. In this procedure, I found that if we can apply the call policies before the argument conversion procedure and in the context of the call policy object (a call policy object is always attached with a method, right?), the problem will be solved much easier and safer. We'll be able to replace the PyUnicode object with a PyString object (in Windows platform, always MBCS encoding), maybe save the original args tuple in the call policy object, then convert the args to C++ (it'll success because the arg is a PyString) and call the C++ function, when postcall(args, result) called, we can just release the newly allocated args tuple, replace it with the original one. This will give us more control on how the args be processed. Lijun Qin http://www.solidshare.com From dave at boost-consulting.com Fri Aug 1 13:15:29 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 01 Aug 2003 07:15:29 -0400 Subject: [C++-sig] Re: Automatic PyUnicode to 'const char*' References: <20030731174424.7728.63710.Mailman@mail.python.org> <005001c3588a$805b8b00$0200a8c0@barrack> Message-ID: "Lijun Qin" writes: > Hi, all: > > I have found a method to do this, by register a convert function: > > inline void* convert_to_cstring_from_unicode(PyObject* obj) > { > if (!PyUnicode_Check(obj)) return 0; > PyObject* str = PyUnicode_AsEncodedString(obj, "mbcs", NULL); > if (!str) throw_error_already_set(); > > //We must release the str before we return to python, gard here > static leak_gard _gard; > > unicode_str_map[obj] = str; > return PyString_AsString(str); > } > > converter::registry::insert(convert_to_cstring_from_unicode, > type_id()); > > But the problem is that the PyString object must be freed when the > call is completed, I currently do this by applying a custom call > policy to the methods using 'const char*' type of parameters, but if > there were reclusive "recursive", I think. > calls into the same fuction, it'll much complex. > > In this procedure, I found that if we can apply the call policies > before the argument conversion procedure and in the context of the > call policy object (a call policy object is always attached with a > method, right?) Right. > the problem will be solved much easier and safer. We'll be able to > replace the PyUnicode object with a PyString object (in Windows > platform, always MBCS encoding), maybe save the original args tuple > in the call policy object This is the key thing which I had forgotten: call policies can have state. You can keep a stack (linked list) of "original args tuples" in the call policy in order to deal with recursion. > then convert the args to C++ (it'll success because the arg is a > PyString) and call the C++ function, when postcall(args, result) > called, we can just release the newly allocated args tuple, replace > it with the original one. This will give us more control on how the > args be processed. Yes, that sounds brilliant! So this approach does not use the convert_to_cstring_from_unicode converter, correct? I think it has inspired me, also, to consider expanding the conversion interface. I was looking for a way for converters to maintain state (e.g. to be able to keep a PyString alive during the conversion, or to be able to fabricate a vector from a Python list and then write the modified elements of the vector back into the list after the call) without incurring the cost of a polymorphic postcall operation for each converter in a function call. One possibility might be to define an abstract postcall object, and pass a pointer to a chain of those, which lives in the call policy, to all converters during function calls. Any converter which needed to maintain state could add a postcall object to the chain. That would essentially reduce the postcall check to a single step for N arguments, in the usual case that there were no postcall operations. In non-function contexts, such as char const* p = extract(s); the pointer to the postcall chain would be NULL, so any converters which required a postcall chain could simply report "no match". -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Fri Aug 1 16:16:37 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 01 Aug 2003 10:16:37 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F294F35.A6988D6A@sitius.com> Message-ID: Nikolay Mladenov writes: > Diffs to the cvs from before couple of days: Hi Nikolay, In future, please post patches as unified diffs (you can use cvs diff -wu). This patch appears to have some significant bogus code in it, especially in function.cpp. Just for example, I think the following block would never be entered: > ! //adjust the parameter tuple size > ! if(j ! { > ! handle<> args3( PyTuple_New(j) ); > ! > ! for (size_t l = 0; l != j; ++ l) > ! { > ! PyTuple_SET_ITEM(args3.get(), l, PyTuple_GET_ITEM(args3.get(), l) ); > ! PyTuple_SET_ITEM(args2.get(), l, 0); > ! } > ! args2 = args3; > ! } > } > } > } It had better not be, because it is getting all the elements of args3 and putting them back there! I've enclosed the modified patch which seems to be working on my machine. I had to rename lots of variables in order to make sense of things. Please look it over to make sure it makes sense to you. -------------- next part -------------- A non-text attachment was scrubbed... Name: nikolay.patch Type: text/x-patch Size: 10857 bytes Desc: not available URL: -------------- next part -------------- -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Fri Aug 1 18:39:25 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 01 Aug 2003 12:39:25 -0400 Subject: [C++-sig] Re: Wrapper for exception translation References: <2040C0A1CA23D51181A30050BAAC990274AAC2@berexch.ber.haufemg.com> <001201c34936$303e0b60$44a837c2@gieke>

<013401c357a6$db402e70$44a837c2@gieke> Message-ID: Gottfried Gan?auge writes: > Hi Dave, > > I digged through the class_<> implementation and I think I know what I must > do to implement it. Like you suggested I would add another argument to the > class_base constructor which is used as another base class for the newly > created class. > > The only problem I'm having is the programming interface for the user: > I could the simply pass a const pointer to the python exception type to the > protected class_<> constructor. This would - at least for my feeling - look > a bit strange because this would be the only low level python detail on this > level. Additionally it would require from the programmer that he knows the > low level name of the exception type. > > Alternatively I could create an object wrapper around the exception types > and pass a const reference to one of those. This is not too complicated but > it takes it's time. Furthermore I'm not sure about your reaction to my plans > being too complicated :-(. Your plans are complex, but comprehensible and clean. So I support them. Ultimately, I'd like to have an object wrapper around all of the exception classes. I'd like to present as much of the Python API as possible at a high level. It would be great if we could also do: throw IndexError(some_argument); And have it mean the same as: >>> raise IndexError, some_argument > I'm on vacation this week and the next so I currently work only > sporadically. > I think I could have a first prototype by monday, august 18. Sounds very promising; I look forward to it! -- Dave Abrahams Boost Consulting www.boost-consulting.com From nickm at sitius.com Fri Aug 1 23:10:10 2003 From: nickm at sitius.com (Nikolay Mladenov) Date: Fri, 01 Aug 2003 17:10:10 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> Message-ID: <3F2AD732.A94E2127@sitius.com> The change that breaks it has happened between Feb 06 2003 and Feb 07 2003 and as far as I can tell it comes from: mpl/aux_/has_xxx.hpp around line 79 the definition of struct msvc_is_incomplete and than detail/iterator.hpp around line 83 What do you think, can it be fixed? Nikolay Nikolay Mladenov wrote: > > David Abrahams wrote: > > > > Nikolay Mladenov ?nickm at sitius.com? writes: > > > > ? I can't get boost_python to compile with this swich, and I have > > ? 1.29.0 compiled with it. > > > > You're saying Boost.Python 1.29.0 used to compile with /vmg? > > Yes. Without a problem. > > > This is compiler insanity, plain and > > simple. > > I can easily believe that:). Though the error seems to come from some > msvc workaround code. > > > > > If indeed it used to compile, all I can suggest is that you do what I > > did this morning: a binary search through time for the CVS change > > which caused /vmg to start failing. Tedious but effective. > > Okey, I 'll try that. From dave at boost-consulting.com Sat Aug 2 04:43:43 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 01 Aug 2003 22:43:43 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> <3F2AD732.A94E2127@sitius.com> Message-ID: Nikolay Mladenov writes: > The change that breaks it has happened between Feb 06 2003 and Feb 07 > 2003 > and as far as I can tell it comes from: > mpl/aux_/has_xxx.hpp around line 79 > the definition of struct msvc_is_incomplete > and than detail/iterator.hpp around line 83 > What do you think, can it be fixed? Maybe. Can you figure out which of these two changes is responsible for your problem? I'm pretty sure it's has_xxx.hpp, but I'd like to know for sure. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Aug 2 04:46:06 2003 From: dave at boost-consulting.com (David Abrahams) Date: Fri, 01 Aug 2003 22:46:06 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> <3F2AD732.A94E2127@sitius.com> Message-ID: Nikolay Mladenov writes: > The change that breaks it has happened between Feb 06 2003 and Feb 07 > 2003 > and as far as I can tell it comes from: > mpl/aux_/has_xxx.hpp around line 79 > the definition of struct msvc_is_incomplete > and than detail/iterator.hpp around line 83 > What do you think, can it be fixed? Hmm, it looks like /vmg has to completely break that msvc_is_incomplete template: template< typename T > struct msvc_is_incomplete { struct incomplete_; BOOST_STATIC_CONSTANT(bool, value = sizeof(void (T::*)()) == sizeof(void (incomplete_::*)()) ); }; I think msvc_is_incomplete::value would always be true. -- Dave Abrahams Boost Consulting www.boost-consulting.com From agurtovoy at meta-comm.com Sat Aug 2 09:21:10 2003 From: agurtovoy at meta-comm.com (Aleksey Gurtovoy) Date: Sat, 2 Aug 2003 02:21:10 -0500 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> <3F2AD732.A94E2127@sitius.com> Message-ID: <00f501c358c6$b8946e10$b344a8c0@metacomm.com> David Abrahams wrote: > Nikolay Mladenov writes: > > > The change that breaks it has happened between Feb 06 2003 and Feb 07 > > 2003 > > and as far as I can tell it comes from: > > mpl/aux_/has_xxx.hpp around line 79 > > the definition of struct msvc_is_incomplete > > and than detail/iterator.hpp around line 83 > > What do you think, can it be fixed? > > Hmm, it looks like /vmg has to completely break that > msvc_is_incomplete template: > > template< typename T > > struct msvc_is_incomplete > { > struct incomplete_; > BOOST_STATIC_CONSTANT(bool, value = > sizeof(void (T::*)()) == sizeof(void (incomplete_::*)()) > ); > }; > > I think msvc_is_incomplete::value would always be true. Yeah. Unfortunately, that's the only way I know to implement 'has_xxx' on MSVC so that it doesn't bark on incomplete types, and there is some code around which relies on it. On the other hand, Boost.Python probably doesn't depend on it, and since '/vmg' is not the default option, what we _can_ do is to guard the 'is_incomplete' check with something like BOOST_MPL_AUX_HAS_XXX_MSVC_NO_IS_INCOMPLETE and ask to define the symbol when compiling with '/vmg' or '#pragma pointers_to_members(full_generality, ...)'. If that sounds like a reasonable compromise - in particular, to Nikolay - please feel free to implement it. Aleksey From dave at boost-consulting.com Sat Aug 2 13:46:17 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 02 Aug 2003 07:46:17 -0400 Subject: [C++-sig] Re: args patch In-Reply-To: <00f501c358c6$b8946e10$b344a8c0@metacomm.com> (Aleksey Gurtovoy's message of "Sat, 2 Aug 2003 02:21:10 -0500") References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> <3F2AD732.A94E2127@sitius.com> <00f501c358c6$b8946e10$b344a8c0@metacomm.com> Message-ID: Aleksey Gurtovoy writes: > David Abrahams wrote: >> Nikolay Mladenov writes: >> >> > The change that breaks it has happened between Feb 06 2003 and Feb 07 >> > 2003 >> > and as far as I can tell it comes from: >> > mpl/aux_/has_xxx.hpp around line 79 >> > the definition of struct msvc_is_incomplete >> > and than detail/iterator.hpp around line 83 >> > What do you think, can it be fixed? >> >> Hmm, it looks like /vmg has to completely break that >> msvc_is_incomplete template: >> >> template< typename T > >> struct msvc_is_incomplete >> { >> struct incomplete_; >> BOOST_STATIC_CONSTANT(bool, value = >> sizeof(void (T::*)()) == sizeof(void (incomplete_::*)()) >> ); >> }; >> >> I think msvc_is_incomplete::value would always be true. > > Yeah. Unfortunately, that's the only way I know to implement 'has_xxx' on > MSVC so that it doesn't bark on incomplete types, and there is some code > around which relies on it. It seems to me that it can't know the answer for incomplete types, and therefore it shouldn't produce one - it should be an error. How does the conforming version manage it? > On the other hand, Boost.Python probably doesn't depend on it Right. > and since '/vmg' is not the default option, what we _can_ do is to > guard the 'is_incomplete' check with something like > BOOST_MPL_AUX_HAS_XXX_MSVC_NO_IS_INCOMPLETE and ask to define the > symbol when compiling with '/vmg' or '#pragma > pointers_to_members(full_generality, ..)'. Sounds like a plan. > If that sounds like a reasonable compromise - in particular, to > Nikolay - please feel free to implement it. Nikolay, let me know what you think. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Sat Aug 2 18:01:55 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 02 Aug 2003 12:01:55 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> <3F2AD732.A94E2127@sitius.com> <00f501c358c6$b8946e10$b344a8c0@metacomm.com> Message-ID: Aleksey Gurtovoy writes: >> I think msvc_is_incomplete::value would always be true. > > Yeah. Unfortunately, that's the only way I know to implement 'has_xxx' on > MSVC so that it doesn't bark on incomplete types, and there is some code > around which relies on it. On the other hand, Boost.Python probably doesn't > depend on it, and since '/vmg' is not the default option, what we _can_ do > is to guard the 'is_incomplete' check with something like > BOOST_MPL_AUX_HAS_XXX_MSVC_NO_IS_INCOMPLETE and ask to define the symbol > when compiling with '/vmg' or '#pragma pointers_to_members(full_generality, > ...)'. > > If that sounds like a reasonable compromise - in particular, to Nikolay - > please feel free to implement it. I did you one better. Now it just works with no BOOST_MPL_AUX_HAS_XXX_MSVC_NO_IS_INCOMPLETE switches required from the user: --- has_xxx.hpp 8 Jul 2003 05:10:02 -0000 1.16 +++ has_xxx.hpp 2 Aug 2003 15:58:44 -0000 1.17 @@ -3,8 +3,8 @@ // See http://www.boost.org for updates, documentation, and revision history. //----------------------------------------------------------------------------- // -// Copyright (c) 2002 -// Aleksey Gurtovoy +// Copyright (c) 2002-2003 +// Aleksey Gurtovoy and David Abrahams // // Permission to use, copy, modify, distribute and sell this software // and its documentation for any purpose is hereby granted without fee, @@ -73,10 +73,14 @@ template< typename T > struct msvc_is_incomplete { - struct incomplete_; - BOOST_STATIC_CONSTANT(bool, value = - sizeof(void (T::*)()) == sizeof(void (incomplete_::*)()) - ); + // MSVC is capable of some kinds of SFINAE. If U is an incomplete + // type, it won't pick the second overload + static char tester(...); + template + static char(& tester(type_wrapper) )[sizeof(U) + 1]; + + BOOST_STATIC_CONSTANT( + bool, value = sizeof(tester(type_wrapper())) == 1); }; -- Dave Abrahams Boost Consulting www.boost-consulting.com From nickm at sitius.com Sat Aug 2 21:43:15 2003 From: nickm at sitius.com (Nikolay Mladenov) Date: Sat, 02 Aug 2003 15:43:15 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F294F35.A6988D6A@sitius.com> Message-ID: <3F2C1453.255B036D@sitius.com> David Abrahams wrote: > > Nikolay Mladenov writes: > > > Diffs to the cvs from before couple of days: > > Hi Nikolay, > > In future, please post patches as unified diffs (you can use cvs diff > -wu). > > This patch appears to have some significant bogus code in it, > especially in function.cpp. Just for example, I think the following > block would never be entered: > > > ! //adjust the parameter tuple size > > ! if(j > ! { > > ! handle<> args3( PyTuple_New(j) ); > > ! > > ! for (size_t l = 0; l != j; ++ l) > > ! { > > ! PyTuple_SET_ITEM(args3.get(), l, PyTuple_GET_ITEM(args3.get(), l) ); > > ! PyTuple_SET_ITEM(args2.get(), l, 0); > > ! } > > ! args2 = args3; > > ! } > > } > > } > > } > > It had better not be, because it is getting all the elements of args3 > and putting them back there! Yeah, I don't remember if the things have been different when I wrote this or I have just imagined that I can end up with min_arity < n_args < max_arity. I guess I have meant to copy arg2 -> arg3 > > ! PyTuple_SET_ITEM(args3.get(), l, PyTuple_GET_ITEM(args2.get(), l) ); But anyway it seems really unreachable now. > > I've enclosed the modified patch which seems to be working on my > machine. I had to rename lots of variables in order to make sense of > things. Please look it over to make sure it makes sense to you. > I like it better. Please apply it. Nikolay From dave at boost-consulting.com Sat Aug 2 22:21:40 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sat, 02 Aug 2003 16:21:40 -0400 Subject: [C++-sig] Re: Boost.Python unnamed enums at global scope In-Reply-To: <3F2C1CDF.26797.29B50CEC@localhost> (Niall Douglas's message of "Sat, 2 Aug 2003 20:19:43 +0100") References: <3F2C1CDF.26797.29B50CEC@localhost> Message-ID: Hi Niall, Please post Boost.Python questions to the C++-sig (see http://www.boost.org/more/mailing_lists.htm). "Niall Douglas" writes: > Hi, > > I was wondering if Boost.Python could be extended such that: > > enum_("").value("CONST", CONST); > > .. would place its members in the highest scope possible ie; you'd > access it as my_module.CONST. We have an export_values() member function which accomplishes that. http://www.boost.org/libs/python/doc/v2/enum.html#enum_-spec > I suggest this because the library I'm creating bindings for has > loads of unnamed enums at global scope for creating constants and > sticking them in some "unnamed" scope is counter-intuitive. Since > pyste has to deal with these, it creates problems :( If you're using Pyste, you *really* should post this to the C++-sig, since Nicodemus (the Pyste author) doesn't read my emails. -- Dave Abrahams Boost Consulting www.boost-consulting.com From nicodemus at globalite.com.br Sat Aug 2 22:55:25 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sat, 2 Aug 2003 17:55:25 -0300 Subject: [C++-sig] Re: Boost.Python unnamed enums at global scope References: <3F2C1CDF.26797.29B50CEC@localhost> Message-ID: <001001c35938$692021e0$0101a8c0@sergio> ----- Original Message ----- From: "David Abrahams" To: "Niall Douglas" ; "pysig" Sent: Saturday, August 02, 2003 5:21 PM Subject: [C++-sig] Re: Boost.Python unnamed enums at global scope > > Hi Niall, > > Please post Boost.Python questions to the C++-sig (see > http://www.boost.org/more/mailing_lists.htm). > > "Niall Douglas" writes: >> I was wondering if Boost.Python could be extended such that: >> >> enum_("").value("CONST", CONST); >> >> .. would place its members in the highest scope possible ie; you'd >> access it as my_module.CONST. > > We have an export_values() member function which accomplishes that. > > http://www.boost.org/libs/python/doc/v2/enum.html#enum_-spec > > > I suggest this because the library I'm creating bindings for has > > loads of unnamed enums at global scope for creating constants and > > sticking them in some "unnamed" scope is counter-intuitive. Since > > pyste has to deal with these, it creates problems :( Nice, I didn't know that either. I think this mirrors the enum behaviour of C++ better. How should Pyste support this? I believe it is more interesting if Pyste always called export_values(), but this would break backwards compability. Thoughts? Niall, another solution would be to explicitly export the names to the global namespace in the Python side (untested): # my_module.py import _my_module # this is the extension module for name, value in _my_module.unnamed.__dict__: globals()[name] = value with this, your users now just have to: import my_module x = my_module.CONST etc etc From agurtovoy at meta-comm.com Sat Aug 2 23:02:16 2003 From: agurtovoy at meta-comm.com (Aleksey Gurtovoy) Date: Sat, 2 Aug 2003 16:02:16 -0500 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

<3F25D683.B25CBCAF@sitius.com> <3F2939B0.4B8047E8@sitius.com> <3F29514D.506729DF@sitius.com> <3F296B6B.BDB7991A@sitius.com> <3F2AD732.A94E2127@sitius.com> <00f501c358c6$b8946e10$b344a8c0@metacomm.com> <026801c3593b$5a0845e0$b344a8c0@metacomm.com> Message-ID: "Brett Calcott" writes: > Is this patch MS version specific? > > Trying to build using VC7 from latest cvs with this patch: > > > ...failed vc-C++ > ..\..\..\libs\python\build\bin\boost_python.dll\msvc\debug\runtime-link-dyna > mic\numeric.obj... > vc-C++ > ..\..\..\libs\python\build\bin\boost_python.dll\msvc\debug\runtime-link-dyna > mic\list.obj > list.cpp > X:/boost/boost/mpl/aux_/has_xxx.hpp|80 error 2988| unrecognizable template > declaration/definition > X:/boost/boost/mpl/aux_/has_xxx.hpp|84| see reference to class > template instantiation 'boost::mpl::aux::msvc_is_incomplete' being > compiled > X:/boost/boost/mpl/aux_/has_xxx.hpp|80 error 2059| syntax error : ' Parse>' > X:/boost/boost/mpl/aux_/has_xxx.hpp|82 error 2332| 'enum' : missing tag name > X:/boost/boost/mpl/aux_/has_xxx.hpp|82 error 2238| unexpected token(s) > preceding ';' Fixed now, sorry. -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Sun Aug 3 16:19:28 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 15:19:28 +0100 Subject: [C++-sig] Re: Boost.Python unnamed enums at global scope In-Reply-To: References: <3F2C57FC.24354.2A9BF6C0@localhost> (Niall Douglas's message of "Sun, 3 Aug 2003 00:31:56 +0100") Message-ID: <3F2D2800.26671.2DC883D7@localhost> On 3 Aug 2003 at 0:33, David Abrahams wrote: > > d:\Tornado\TClient\boost\boost\python\operators.hpp(190) : error > > C2678: binary '<<' : no operator found which takes a left-hand > > operand of type 'const boost::python::detail::unwrap_other::type' > > (or there is no acceptable conversion) > > with > > [ > > T=boost::python::other > > ] > > d:\Tornado\TClient\boost\boost\python\operators.hpp(190) : > > while compiling class-template member function 'PyObject > > *boost::python::detail::operator_r::apply::execute(c > > on st R &,const L &)' > > with > > [ > > > > L=boost::python::detail::unwrap_other > ea m>>::type, > > R=FX::FXId > > ] > > d:\Tornado\TClient\boost\boost\python\operators.hpp(63) : > > see > > reference to class template instantiation > > 'boost::python::detail::operator_r::apply' being > > compiled > > with > > [ > > > > L=boost::python::detail::unwrap_other > ea m>>::type, > > R=FX::FXId > > ] > > d:\Tornado\TClient\boost\boost\python\operators.hpp(107) : > > see reference to class template instantiation > > 'boost::python::detail::operator_r_inner' being compiled > > with > > [ > > id=op_lshift, > > > > L=boost::python::detail::unwrap_other > ea m>>::type, > > R=FX::FXId > > ] > > d:\Tornado\TClient\boost\boost\python\class.hpp(330) : see > > reference to class template instantiation > > 'boost::python::detail::binary_op_r::apply' being compiled > > with > > [ > > id=op_lshift, > > > > L=boost::python::detail::unwrap_other > ea m>>::type, > > T=FX::FXId > > ] > > d:\Tornado\TClient\TnFOX\pythonbinds\_tnfox.cpp(1846) : see > > reference to function template instantiation > > 'boost::python::class_::self > > &boost::python::class_::def > FX ::FXStream>,boost::python::self_ns::self_t>(const > > boost::python::detail::operator_ &)' being compiled > > with > > [ > > T=FX::FXId, > > X1=boost::noncopyable, > > X2=`anonymous-namespace'::FX_FXId_Wrapper, > > id=op_lshift, > > L=boost::python::other, > > R=boost::python::self_ns::self_t > > ] > > > > This results from a user defined << operator which pyste defined > > using .def( other< FX::FXStream >() << self ). This appears to be > > correct. > > What appears to be correct? How pyste has generated the << operator specification ie; I'm saying pyste appears to be generating the right code. > > The same problem occurs for the >> operator and furthermore it seems > > to happen with basic types as well as user defined ones (though > > still working with FXStream). Removing them all makes the problem go > > away :) > > Removing what makes the problem go away? The definition ie; remove all overloads of the << and >> operators. > What compiler are you using? MSVC7.1 > Can you post a small reproducible test case? I'll get onto it. Cheers, Niall From s_sourceforge at nedprod.com Sun Aug 3 17:45:11 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 16:45:11 +0100 Subject: [C++-sig] Failure to deduce template argument types Message-ID: <3F2D3C17.24124.2E16FF13@localhost> What's going on here? (MSVC7.1): d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector17 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14) volatile)' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17) volatile' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector17 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14) const)' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17) const' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector17 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14))' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16,T17)' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector16 boost::python::detail::get_signature(RT (__cdecl *)(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14))' : could not deduce template argument for 'T1 (__cdecl *)(T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16)' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(89) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector16 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13) volatile const)' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16) volatile const' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector16 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13) volatile)' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16) volatile' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector16 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13) const)' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16) const' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector16 boost::python::detail::get_signature(RT (__thiscall ClassT::* )(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13))' : could not deduce template argument for 'T1 (__thiscall T2::* )(T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15,T16)' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(111) : see declaration of 'boost::python::detail::get_signature' d:\Tornado\TClient\boost\boost\python\make_function.hpp(95) : error C2784: 'boost::mpl::vector15 boost::python::detail::get_signature(RT (__cdecl *)(T0,T1,T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13))' : could not deduce template argument for 'T1 (__cdecl *)(T2,T3,T4,T5,T6,T7,T8,T9,T10,T11,T12,T13,T14,T15)' from 'FX::FXuint (__cdecl *)(FX::FXWindow *,FX::FXuint,const char *,const char *,...)' d:\Tornado\TClient\boost\boost\python\signature.hpp(89) : see declaration of 'boost::python::detail::get_signature' <... keeps going and going removing the last Tx (eg; vector15, vector14, vector13 etc) from each error ...> Cheers, Niall From s_sourceforge at nedprod.com Sun Aug 3 17:45:11 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 16:45:11 +0100 Subject: [C++-sig] 64 bit integer bug in pyste Message-ID: <3F2D3C17.6006.2E16FDB5@localhost> When using 64 bit integers, GCCXML reports long long. Under MSVC this should be __int64. You could use instead BOOST_PYTHON_LONG_LONG which resolves on all platforms. Cheers, Niall From s_sourceforge at nedprod.com Sun Aug 3 17:45:10 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 16:45:10 +0100 Subject: [C++-sig] Boost.Python << & >> bug Message-ID: <3F2D3C16.13081.2E16FAD0@localhost> 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 another 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: Test.cpp Date: 3 Aug 2003, 16:29 Size: 2899 bytes. Type: Program-source -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.cpp Type: application/octet-stream Size: 2899 bytes Desc: not available URL: From s_sourceforge at nedprod.com Sun Aug 3 17:45:10 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 16:45:10 +0100 Subject: [C++-sig] Boost.Python << & >> bug Message-ID: <3F2D3C16.5165.2E16FB3E@localhost> On 3 Aug 2003 at 15:14, c++-sig at python.org wrote: Enclosed is the condensed example as requested. There are actually two bugs but I think the first (the original) is the same as the second - comment out the FXId one to see the second. What's happening IMHO is that boost.python's wrappings of user types are failing to cast down to their containing types so therefore the compiler gets confused. Hence the error message from before. The second bug is similar (MSVC7.1 report): d:\Tornado\TClient\boost\boost\python\operators.hpp(190) : error C2678: binary '<<' : no operator found which takes a left-hand operand of type 'const FX::FXStream' (or there is no acceptable conversion) d:\Tornado\TClient\boost\boost\python\operators.hpp(190) : while compiling class-template member function 'PyObject *boost::python::detail::operator_l::apply::execute(con st L &,const R &)' with [ L=FX::FXStream, R=boost::python::detail::unwrap_other>::type ] Here because FXStream does not provide an overload for anything in boost, it can't know it's really an unsigned char. Cheers, Niall From s_sourceforge at nedprod.com Sun Aug 3 17:45:10 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 16:45:10 +0100 Subject: [C++-sig] (Fwd) Previous email to Nicodemus Message-ID: <3F2D3C16.27885.2E16FC9C@localhost> ------- Forwarded message follows ------- From: Niall Douglas To: xxxxxxxx at xxxxxxxxx.com.br Subject: Whoops, found newer version of pyste! Date sent: Sat, 2 Aug 2003 20:16:50 +0100 Hi again, Sorry, it only occurred to me after sending the previous email that Boost was probably on CVS. However, the latest version still has the problem with passing backslashes to Win32 GCCXML. It's GCCXML that barfs (and I got the precompiled binary off its web site). Also, unnamed enums don't trap properly, at least here. Changing the line in EnumExporters.Export to: if rename[0:2] == "$_" or rename == '._0': This fixes it. I've looked through the Boost.Python source and I think the changes necessary to make passing "" as the scope name to enter into the upper-most scope are probably quite easy. I'll send an email to Dave Abrahams and see what he says. Next extension: my .pyste file is actually a full blown script which reads the contents of a directory for the header files and then dynamically creates the variable = AllFromHeader(filepath). Hence it needs to know where it lives which currently it can't. I propose adding the following to pyste.py: def CreateContext(interfacepath): 'create the context where a interface file will be executed' context = {} # location context['mylocation'] = interfacepath # infos ... and simply have CreateContext()'s invocation also pass the path of the .pyste file. Now the .pyste file knows where it is, which will be relative to where the header files will be. Next idea: couldn't pyste automatically recognise properties via a get/set method combo and use .add_property()? It would need to be optional on the command line because some people would consider it too dissimilar from the C++ library original. Next point: pyste seems to want inherited members return policy set for each and every subclass. So if I bind FXWindow and FXTopWindow which inherits FXTopWindow, I must reapply set_policy() for all FXTopWindow's inherited methods from FXWindow. To be honest, this doesn't bother me too much because you can create functions in the .pyste file called applyFXWindow(var) and applyFXTopWindow(var) and the latter simply calls applyFXWindow() on its var before adding its own unique stuff - unfortunately in this case pyste adds too many definitions of BOOST_PYTHON_MEMBER_FUNCTION_OVERLOADS for the same class. Anyway, I just wanted to say that the new version is much better and my thanks to you for it. Time for bed now :) Cheers, Niall ------- End of forwarded message ------- ------- End of forwarded message ------- From nicodemus at globalite.com.br Sun Aug 3 18:06:06 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Sun, 3 Aug 2003 13:06:06 -0300 Subject: [C++-sig] (Fwd) Previous email to Nicodemus References: <3F2D3C16.27885.2E16FC9C@localhost> Message-ID: <001f01c359d9$28512e10$0101a8c0@sergio> Yeah, I didn't got this email before. 8) Thanks for sending again. ----- Original Message ----- From: "Niall Douglas" To: Sent: Sunday, August 03, 2003 12:45 PM Subject: [C++-sig] (Fwd) Previous email to Nicodemus > Hi again, > > However, the latest version still has the problem with passing > backslashes to Win32 GCCXML. It's GCCXML that barfs (and I got the > precompiled binary off its web site). Yes, GCCXML expects forward slashes only. Does this trouble you? > Also, unnamed enums don't trap properly, at least here. Changing the > line in EnumExporters.Export to: > > if rename[0:2] == "$_" or rename == '._0': Hmm, I see. There's no documentation avaiable for GCCXML, so it is kind of a mistery to predict all the weird names that it assigns for unnamed enums. 8) Thanks! > I've looked through the Boost.Python source and I > think the changes necessary to make passing "" as the scope name to > enter into the upper-most scope are probably quite easy. I'll send an > email to Dave Abrahams and see what he says. Yes, I believe you mean export_values(). > Next extension: my .pyste file is actually a full blown script which > reads the contents of a directory for the header files and then > dynamically creates the variable = AllFromHeader(filepath). Nice. That's an advantage of they being python scripts. 8) > Hence it needs to know where it lives which currently it can't. I propose > adding the following to pyste.py: > > def CreateContext(interfacepath): > 'create the context where a interface file will be executed' > context = {} > # location > context['mylocation'] = interfacepath > # infos > > ... and simply have CreateContext()'s invocation also pass the path > of the .pyste file. Now the .pyste file knows where it is, which will > be relative to where the header files will be. I see your problem, but I find the solution kind of a "hack". Have you tried if sys.path[0] gives the directory where the pyste file is? If it doesn't, I think we will have to use this solution, but I prefer following the upper-case conventin for constants: INTERFACE_PATH or something like that. > Next idea: couldn't pyste automatically recognise properties via a > get/set method combo and use .add_property()? It would need to be > optional on the command line because some people would consider it > too dissimilar from the C++ library original. Certainly, and should be easy enough to do. I think a command line is not necessary, because we can always expose the get/set methods and the properties. This will have to wait a little though, because I have lots of fixes to make in Pyste as it is. 8) > Next point: pyste seems to want inherited members return policy set > for each and every subclass. So if I bind FXWindow and FXTopWindow > which inherits FXTopWindow, I must reapply set_policy() for all > FXTopWindow's inherited methods from FXWindow. I think you mistake the classes in this example. Could you clarify? > Anyway, I just wanted to say that the new version is much better and > my thanks to you for it. Time for bed now :) Thanks, and thanks for your feedback! Regards, Nicodemus. From dave at boost-consulting.com Sun Aug 3 19:31:40 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 03 Aug 2003 13:31:40 -0400 Subject: [C++-sig] Re: Failure to deduce template argument types References: <3F2D3C17.24124.2E16FF13@localhost> Message-ID: "Niall Douglas" writes: > What's going on here? (MSVC7.1): How many arguments to the function you're wrapping? See file:///C:/boost/libs/python/doc/v2/configuration.html#app-defined -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Sun Aug 3 21:43:39 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 20:43:39 +0100 Subject: [C++-sig] (Fwd) Previous email to Nicodemus In-Reply-To: <001f01c359d9$28512e10$0101a8c0@sergio> Message-ID: <3F2D73FB.18840.2EF1541A@localhost> On 3 Aug 2003 at 13:06, Nicodemus wrote: > Yeah, I didn't got this email before. 8) > Thanks for sending again. It seems then that there's something wrong with email between us. Maybe your email system thinks I'm spam? ;) > > However, the latest version still has the problem with passing > > backslashes to Win32 GCCXML. It's GCCXML that barfs (and I got the > > precompiled binary off its web site). > > Yes, GCCXML expects forward slashes only. Does this trouble you? Absolutely. On Win32 GCCXML dies a very horrible death if there is a single backslash in its command line. Since pyste takes backslashes in its input off its command line, this creates a problem eg; me passing command line variables to pyste which obviously would contain backslashes. Why on earth couldn't DOS just have taken normal slashes! :( > Hmm, I see. There's no documentation avaiable for GCCXML, so it is > kind of a mistery to predict all the weird names that it assigns for > unnamed enums. 8) Thanks! Not really. GCC itself allocates temporary symbols starting with $. That's why you can't use $ in your own symbol names on most systems. You can see plenty more if you investigate the embedded assembler in GCC. > > Next extension: my .pyste file is actually a full blown script which > > reads the contents of a directory for the header files and then > > dynamically creates the variable = AllFromHeader(filepath). > > Nice. That's an advantage of they being python scripts. 8) It's why python's great! I haven't had so much fun programming in it since BBC Basic V on the Acorn Archimedes (a wonderful system for its day)! A marriage between my C++ and python environments would be ideal ... at least till I get some time to write the lazy functional language I've always wanted to write (Haskell's too esoteric). > I see your problem, but I find the solution kind of a "hack". Have you > tried if sys.path[0] gives the directory where the pyste file is? If > it doesn't, I think we will have to use this solution, but I prefer > following the upper-case conventin for constants: Err, doesn't sys.path refer to the script which invoked python? I think so. Anyway, anything execfile'd is considered not standalone as far as I understand ie; it merely reads the file into a string and compiles that to a code object ie; it's no different from exec. Anyway I've not tried it, and don't have enough experience with python to say for sure, so I'll shut up now :) > > Next point: pyste seems to want inherited members return policy set > > for each and every subclass. So if I bind FXWindow and FXTopWindow > > which inherits FXTopWindow, I must reapply set_policy() for all > > FXTopWindow's inherited methods from FXWindow. > > I think you mistake the classes in this example. Could you clarify? class FXTopWindow : public FXWindow // in FXTopWindow.h { FXObject *foo2(); } class FXWindow // in FXWindow.h { FXObject *foo(); }; If I do AllFromHeader on FXTopWindow.h, it pulls in all the base classes of FXTopWindow (correctly) and then asks for you to set the return policies of foo() and foo2(). Now if I'm also doing FXAllFromHeader on FXWindow.h in the same pyste file, it'll want a return policy set on foo(). My point is that if you've already set the policy for foo() in FXWindow, you also set the policy for all inherited versions of foo() in all subclasses of FXWindow (because apart from covariant return, return types must stay identical in overloads in C++). Therefore you shouldn't need to set it again (except that pyste does actually want you to). Cheers, Niall From s_sourceforge at nedprod.com Sun Aug 3 21:52:56 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Sun, 3 Aug 2003 20:52:56 +0100 Subject: [C++-sig] Re: Failure to deduce template argument types In-Reply-To: Message-ID: <3F2D7628.3245.2EF9D306@localhost> On 3 Aug 2003 at 13:31, David Abrahams wrote: > "Niall Douglas" writes: > > > What's going on here? (MSVC7.1): > > How many arguments to the function you're wrapping? 15, which is exactly the limit. Is the limit inclusive or exclusive? I'll probably find out quicker by recompiling. BTW my inheritence depth exceeds 10. But I assume the limit refers to most classes which can be multiply inherited at one go? Cheers, Niall From dave at boost-consulting.com Mon Aug 4 03:12:10 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 03 Aug 2003 21:12:10 -0400 Subject: [C++-sig] Re: Failure to deduce template argument types References: <3F2D7628.3245.2EF9D306@localhost> Message-ID: "Niall Douglas" writes: > On 3 Aug 2003 at 13:31, David Abrahams wrote: > >> "Niall Douglas" writes: >> >> > What's going on here? (MSVC7.1): >> >> How many arguments to the function you're wrapping? > > 15, which is exactly the limit. Is the limit inclusive or exclusive? > I'll probably find out quicker by recompiling. Don't forget that if it's a member function there's a hidden "this" argument. > > BTW my inheritence depth exceeds 10. But I assume the limit refers to > most classes which can be multiply inherited at one go? Yes. There's no inheritance depth limit. -- Dave Abrahams Boost Consulting www.boost-consulting.com From brett.calcott at paradise.net.nz Mon Aug 4 03:17:04 2003 From: brett.calcott at paradise.net.nz (Brett Calcott) Date: Mon, 4 Aug 2003 11:17:04 +1000 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

Message-ID: > Fixed now, sorry. > Not checked in though? Head is still this: ---------------------------- revision 1.17 date: 2003/08/02 15:58:44; author: david_abrahams; state: Exp; lines: +11 -7 Improved the incomplete type detection workaround for MSVC. It now works even with the /vmg switch which makes all member pointers the same size. ---------------------------- From dave at boost-consulting.com Mon Aug 4 03:22:57 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 03 Aug 2003 21:22:57 -0400 Subject: [C++-sig] Re: Boost.Python << & >> bug References: <3F2D3C16.13081.2E16FAD0@localhost> Message-ID: "Niall Douglas" writes: > // Comment out this for bug no. 2 > scope* FX_FXId_scope = new scope( > class_< FX::FXId >("FXId", no_init) > .def( other< FX::FXStream >() << self ) > .def( other< FX::FXStream >() >> self ) > ); Niall, Why are you dynamically allocating (and leaking) scope objects? That's very bad juju (but probably has nothing to do with your other problems). -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Aug 4 03:41:23 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 03 Aug 2003 21:41:23 -0400 Subject: [C++-sig] Re: Boost.Python << & >> bug References: <3F2D3C16.5165.2E16FB3E@localhost> Message-ID: "Niall Douglas" writes: > On 3 Aug 2003 at 15:14, c++-sig at python.org wrote: > > Enclosed is the condensed example as requested. I assume you're referring to the enclosure in the other message? > There are actually > two bugs but I think the first (the original) is the same as the > second - comment out the FXId one to see the second. It's not clear what you want me to comment out. Please next time include a preprocessor directive which makes the change #ifdef BUG1 ... #else ... #endif > What's happening IMHO is that boost.python's wrappings of user types > are failing to cast down to their containing types I don't know what that means. > so therefore the compiler gets confused. Hence the error message > from before. No this is a failure of your wrapping code. Very simply, class_< FX::FXId >("FXId", no_init) .def( other< FX::FXStream >() << self ) .def( other< FX::FXStream >() >> self ) Attempts to wrap two operator expressions which take an FXStream on the lhs and and FXId on the rhs. But you don't have anything which would match those expressions. Try it: // C++ code FXStream x; FXId y; x << y; // <== error friend FX::FXStream& operator<<(FX::FXStream& store,const FXId* obj){return store;} friend FX::FXStream& operator>>(FX::FXStream& store,FXId*& obj){return store;} These declare operators which take an FXId* on the rhs: x << &y; > The second bug is similar (MSVC7.1 report): > > d:\Tornado\TClient\boost\boost\python\operators.hpp(190) : error > C2678: binary '<<' : no operator found which takes a left-hand > operand of type 'const FX::FXStream' (or there is no acceptable > conversion) > d:\Tornado\TClient\boost\boost\python\operators.hpp(190) : > while compiling class-template member function 'PyObject > *boost::python::detail::operator_l::apply::execute(con > st L &,const R &)' > with > [ > L=FX::FXStream, > > R=boost::python::detail::unwrap_other char>>::type > ] > > Here because FXStream does not provide an overload for anything in > boost, it can't know it's really an unsigned char. I don't know what that means either. The problem you're seeing above may be due to a documentation bug on my part. These operator wrapping facilities are only suitable for wrapping operators which work on rvalue arguments. If you want to wrap your operators which work on non-const lvalues, you should write something more like: FXStream& (FXStream::*pmf)(FXchar&) = &FXStream::operator<<; ... .def('__lshift__', pmf, return_self()); FWIW, Wrapping all these different operators for lots of different integer types is probably a waste of time because Python only has one int type. Wrapping overloads on int and ushort, for example, is redundant. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dawson at physics.uq.edu.au Mon Aug 4 03:55:05 2003 From: dawson at physics.uq.edu.au (Christopher Dawson) Date: Mon, 04 Aug 2003 11:55:05 +1000 Subject: [C++-sig] Subscript Operators In-Reply-To: References: <3F2D3C16.13081.2E16FAD0@localhost> Message-ID: <3F2DBCF9.6000404@physics.uq.edu.au> Hi there, I am attempting to wrap a Matrix class using Boost::Python, for the most part it has been pleasantly easy. However I have been unable to wrap the subscripting operator (int,int) to something similar in python. Is this currently possible and if so can anyone help? Regards, Chris. From dave at boost-consulting.com Mon Aug 4 05:07:05 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 03 Aug 2003 23:07:05 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

Message-ID: "Brett Calcott" writes: >> Fixed now, sorry. >> > > Not checked in though? > > Head is still this: > > ---------------------------- > revision 1.17 > date: 2003/08/02 15:58:44; author: david_abrahams; state: Exp; lines: > +11 -7 > Improved the incomplete type detection workaround for MSVC. It now > works even with the /vmg switch which makes all member pointers the > same size. > ---------------------------- I beg to differ: ---------------------------- revision 1.18 date: 2003/08/03 11:48:55; author: david_abrahams; state: Exp; lines: +15 -1 Workaround for a heinous vc7 bug ---------------------------- Index: has_xxx.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/mpl/aux_/has_xxx.hpp,v retrieving revision 1.17 retrieving revision 1.18 diff -w -u -c -w -u -r1.17 -r1.18 cvs server: conflicting specifications of output style cvs server: conflicting specifications of output style --- has_xxx.hpp 2 Aug 2003 15:58:44 -0000 1.17 +++ has_xxx.hpp 3 Aug 2003 11:48:55 -0000 1.18 @@ -70,14 +70,28 @@ struct has_xxx_tag; +# if BOOST_WORKAROUND(BOOST_MSVC, == 1300) + template + struct msvc_incomplete_array + { + typedef char (&type)[sizeof(U) + 1]; + }; +# endif + template struct msvc_is_incomplete { // MSVC is capable of some kinds of SFINAE. If U is an incomplete // type, it won't pick the second overload static char tester(...); + +# if BOOST_WORKAROUND(BOOST_MSVC, == 1300) + template + static typename msvc_incomplete_array::type tester(type_wrapper); +# else template static char(& tester(type_wrapper) )[sizeof(U) + 1]; +# endif BOOST_STATIC_CONSTANT( bool, value = sizeof(tester(type_wrapper())) == 1); -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Aug 4 05:10:29 2003 From: dave at boost-consulting.com (David Abrahams) Date: Sun, 03 Aug 2003 23:10:29 -0400 Subject: [C++-sig] Re: Boost.Python << & >> bug References: <3F2D3C16.5165.2E16FB3E@localhost> Message-ID: David Abrahams writes: > The problem you're seeing above may be due to a documentation bug on > my part. These operator wrapping facilities are only suitable for > wrapping operators which work on rvalue arguments. If you want to > wrap your operators which work on non-const lvalues, you should write > something more like: > > FXStream& (FXStream::*pmf)(FXchar&) = &FXStream::operator<<; > > ... > .def('__lshift__', pmf, return_self()); Hmm, I could change those wrappers so that the "self" argument was required to be an lvalue. That would preclude implicit conversions to the self type from being used, but it would allow the self object to be mutated by the call. I doubt it would break any real code. Thoughts from the group? -- Dave Abrahams Boost Consulting www.boost-consulting.com From romany at actimize.com Mon Aug 4 09:36:43 2003 From: romany at actimize.com (Roman Yakovenko) Date: Mon, 4 Aug 2003 10:36:43 +0300 Subject: [C++-sig] a few questions about properties Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027AFF@exchange.adrembi.com> Hi. For all question I will introduce here I find solution. But I don't fill good with them. So... struct CConst { private: explicit CConst( int i ) : m_value(i){}; public: const static CConst const_1; const static CConst const_2; int get_value() const { return m_value; } const int& get_value_by_ref() const { return m_value; } private: int m_value; }; const CConst CConst::const_1(1); const CConst CConst::const_2(2); const CConst& get_const_1() { return CConst::const_1; } const CConst& get_const_2() { return CConst::const_2; } BOOST_PYTHON_MODULE(py_smart_const) { class_( "CConst", no_init ) .add_property( "value", &CConst::get_value ) //error .add_property( "value", &CConst::get_value_by_ref ) .def( "const_1", &get_const_1, return_value_policy< reference_existing_object >() ) .staticmethod("const_1") .def( "const_2", &get_const_2, return_value_policy< reference_existing_object >() ) .staticmethod("const_2"); } The first question is how can I add class property? In my example I write 2 functions get_const_1 and get_const_2 and also I get staticmethod and not class property. The second one is how can I specify property return value policy? In my example .add_property( "value", &CConst::get_value_by_ref ) will not compile with error specify_a_return_value_policy_to_wrap_functions_returning. I think that there is no special reason ( except luck of time ), am I right? Thanks. Roman. From brett.calcott at paradise.net.nz Mon Aug 4 09:53:21 2003 From: brett.calcott at paradise.net.nz (Brett Calcott) Date: Mon, 4 Aug 2003 17:53:21 +1000 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2527FC.50969E27@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

Message-ID: > > I beg to differ: > ---------------------------- > revision 1.18 > date: 2003/08/03 11:48:55; author: david_abrahams; state: Exp; lines: +15 -1 > Workaround for a heinous vc7 bug > ---------------------------- weird. I saved the output of cvs log command, and it definitely had 1.17 as the head this morning (GMT+10). X:\boost\boost\mpl\aux_>ls -l temp -rw-rw-rw- 1 user group 3501 Aug 4 11:15 temp X:\boost\boost\mpl\aux_>cat temp RCS file: /cvsroot/boost/boost/boost/mpl/aux_/has_xxx.hpp,v Working file: has_xxx.hpp head: 1.17 ... It doesn't now though. Thanks, Brett From pierre.barbier at cirad.fr Mon Aug 4 10:15:07 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Mon, 04 Aug 2003 10:15:07 +0200 Subject: [C++-sig] Re: cvs anonymous user access denied In-Reply-To: References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027AFC@exchange.adrembi.com> Message-ID: <3F2E160B.2000804@cirad.fr> As there are problems with the CVS version right now, I'm trying to get the nightly tarball's in order to check my directories (it's too slow to do this using the web browsing CVS interface) but I can't get any of these thow ! When trying to get the sourceforge one, I get a "404: Not Found" error, and when trying to get the boost-consulting tgz, I get a "403: Forbidden" error. David Abrahams wrote: >Alternatively, you can download last night's CVS tarball and use >local CVS on your machine: > > http://cvs.sourceforge.net/cvstarballs/boost-cvsroot.tar.gz > >or, from two nights ago: > > http://www.boost-consulting.com/boost-cvsroot.tar.gz > >Good luck, > > -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 From dave at boost-consulting.com Mon Aug 4 13:44:20 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 04 Aug 2003 07:44:20 -0400 Subject: [C++-sig] Re: args patch References: <3F2440E7.C2000F56@sitius.com> <3F2556E3.3F4C0A8C@sitius.com>

Message-ID: "Brett Calcott" writes: >> >> I beg to differ: >> ---------------------------- >> revision 1.18 >> date: 2003/08/03 11:48:55; author: david_abrahams; state: Exp; lines: > +15 -1 >> Workaround for a heinous vc7 bug >> ---------------------------- > > > weird. I saved the output of cvs log command, and it definitely had 1.17 as > the head this morning (GMT+10). > > X:\boost\boost\mpl\aux_>ls -l temp > -rw-rw-rw- 1 user group 3501 Aug 4 11:15 temp > > X:\boost\boost\mpl\aux_>cat temp > > RCS file: /cvsroot/boost/boost/boost/mpl/aux_/has_xxx.hpp,v > Working file: has_xxx.hpp > head: 1.17 > ... > > > It doesn't now though. For the rest of this month, the anonymous CVS is about 24 hours behind the developer CVS, FWIW. -- Dave Abrahams Boost Consulting www.boost-consulting.com From pierre.barbier at cirad.fr Mon Aug 4 15:16:39 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Mon, 04 Aug 2003 15:16:39 +0200 Subject: [C++-sig] Two patches for g++-3.2 Message-ID: <3F2E5CB7.4050107@cirad.fr> Hi, the latest CVS version of boost did not compile with g++-3.2. There were an error in the MPL with the forward definition of the quote3 template class. I found a patch that works fine with g++-3.2 and should work with other compiler. Another problem was in cast.hpp in which g++ complained about a too big integer to be signed. I modified the line according to what's written in /usr/include/stdint.h on my linux distribution. And now there is no more error, and it still should be compatible with every compiler. I hope I didn't make any mistake ... -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_if.hpp Type: text/x-c++hdr Size: 383 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch_cast.hpp Type: text/x-c++hdr Size: 340 bytes Desc: not available URL: From dave at boost-consulting.com Mon Aug 4 17:49:32 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 04 Aug 2003 11:49:32 -0400 Subject: [C++-sig] Anonymous CVS mirror Message-ID: After several days of work, there is now an anonymous mirror of our CVS repository, decompressed each night from the current SourceForge CVS tarball: cvs -d :pserver:anonymous at boost-consulting.com:/boost login cvs -d :pserver:anonymous at boost-consulting.com:/boost co boost Enjoy, Dave -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Mon Aug 4 17:52:43 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 04 Aug 2003 11:52:43 -0400 Subject: [C++-sig] Re: Two patches for g++-3.2 References: <3F2E5CB7.4050107@cirad.fr> Message-ID: Pierre Barbier de Reuille writes: > Hi, > > the latest CVS version of boost did not compile with g++-3.2. There > were an error in the MPL with the forward definition of the quote3 > template class. > I found a patch that works fine with g++-3.2 and should work with > other compiler. > > Another problem was in cast.hpp in which g++ complained about a too > big integer to be signed. I modified the line according to what's > written in /usr/include/stdint.h on my linux distribution. And now > there is no more error, and it still should be compatible with every > compiler. > > I hope I didn't make any mistake ... The first fix doesn't work; I checked in something better. Thanks for the second; that warning's been bothering me! -- Dave Abrahams Boost Consulting www.boost-consulting.com From abeyer at uni-osnabrueck.de Mon Aug 4 18:18:52 2003 From: abeyer at uni-osnabrueck.de (abeyer at uni-osnabrueck.de) Date: Mon, 4 Aug 2003 18:18:52 +0200 (CEST) Subject: [C++-sig] Python 2.3 Message-ID: <1536.192.124.248.20.1060013932.squirrel@webmail.rz.uni-osnabrueck.de> I am trying to use Boost.Python 1.30.0 with Python 2.3 under Windows XP. I have successfully built the Boost.Python lib with MinGW for Python 2.2.3, but I failed for 2.3. Of course, I have set the PYTHON_ROOT and PYTHON_VERSION variables for the new version. Has anyone else encountered problems when compiling Boost.Python for Python 2.3? Here are the details (using Bjam 3.1.4): g++ -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -fn o-inline -I"..\..\..\libs\python\build" -isystem "C:\boost_1_30_0" -isystem "C:\Python23\include" -o "..\..\..\libs\python\build\bin\boost_python.dll\mingw\debug\runtime-link-dynamic\numeric.obj" "..\..\..\libs\python\build\../src\numeric.cpp" mingw-C++-action ..\..\..\libs\python\build\bin\boost_python.dll\mingw\debug\runtime-link-dynamic\numeric.obj In file included from C:/boost_1_30_0/boost/python/converter/arg_to_python.hpp:18, from C:/boost_1_30_0/boost/python/call.hpp:14, from C:/boost_1_30_0/boost/python/object_core.hpp:14, from C:/boost_1_30_0/boost/python/object.hpp:9, from C:/boost_1_30_0/boost/python/tuple.hpp:9, from C:/boost_1_30_0/boost/python/numeric.hpp:9, from ../../../libs/python/src/numeric.cpp:7: C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: parse error before `&' token C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: syntax error before `&' token C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: parse error before `const' C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: syntax error before `const' C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: parse error before `>' token [... and so on ...] From conanb at STCG.net Mon Aug 4 19:25:49 2003 From: conanb at STCG.net (Conan Brink) Date: Mon, 4 Aug 2003 10:25:49 -0700 Subject: [C++-sig] Python 2.3 Message-ID: Python 2.3 changed the name of LONG_LONG to PY_LONG_LONG. Option 1: I solved this in my local copy of 1.30.0 by checking the python version, and if it is >= 2.3, I use PY_LONG_LONG, and if it is < 2.3, I use LONG_LONG. So my lines 103-106 of boost/python/converter/builtin_converters.hpp have been replaced by the following eight lines (apologies if this lousy mail client has messed up the formatting): # ifdef HAVE_LONG_LONG # if PY_MAJOR_VERSION < 2 || PY_MAJOR_VERSION == 2 && PY_MINOR_VERSION <= 2 BOOST_PYTHON_TO_PYTHON_BY_VALUE(signed LONG_LONG, PyLong_FromLongLong(x)) BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned LONG_LONG, PyLong_FromUnsignedLongLong(x)) # else BOOST_PYTHON_TO_PYTHON_BY_VALUE(signed PY_LONG_LONG, PyLong_FromLongLong(x)) BOOST_PYTHON_TO_PYTHON_BY_VALUE(unsigned PY_LONG_LONG, PyLong_FromUnsigned # endif # endif Similar changes then become required in libs/python/src/converter/builtin_converters.cpp and libs/python/test/test_builtin_converters.cpp Option 2: You could #define LONG_LONG as PY_LONG_LONG if your python version is >= 2.3 (or, alternatively, #define PY_LONG_LONG to be LONG_LONG if your version is < 2.3, and then also change all other occurrences of LONG_LONG to PY_LONG_LONG). Option 3: The CVS version of Boost.Python introduces BOOST_PYTHON_LONG_LONG, which then frees you from having to care about which version of Python you're using (for this particular issue). -Conan -----Original Message----- From: abeyer at uni-osnabrueck.de [mailto:abeyer at uni-osnabrueck.de] Sent: Monday, August 04, 2003 9:19 AM To: c++-sig at python.org Subject: [C++-sig] Python 2.3 I am trying to use Boost.Python 1.30.0 with Python 2.3 under Windows XP. I have successfully built the Boost.Python lib with MinGW for Python 2.2.3, but I failed for 2.3. Of course, I have set the PYTHON_ROOT and PYTHON_VERSION variables for the new version. Has anyone else encountered problems when compiling Boost.Python for Python 2.3? Here are the details (using Bjam 3.1.4): g++ -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -fn o-inline -I"..\..\..\libs\python\build" -isystem "C:\boost_1_30_0" -isystem "C:\Python23\include" -o "..\..\..\libs\python\build\bin\boost_python.dll\mingw\debug\runtime-lin k-dynamic\numeric.obj" "..\..\..\libs\python\build\../src\numeric.cpp" mingw-C++-action ..\..\..\libs\python\build\bin\boost_python.dll\mingw\debug\runtime-link -dynamic\numeric.obj In file included from C:/boost_1_30_0/boost/python/converter/arg_to_python.hpp:18, from C:/boost_1_30_0/boost/python/call.hpp:14, from C:/boost_1_30_0/boost/python/object_core.hpp:14, from C:/boost_1_30_0/boost/python/object.hpp:9, from C:/boost_1_30_0/boost/python/tuple.hpp:9, from C:/boost_1_30_0/boost/python/numeric.hpp:9, from ../../../libs/python/src/numeric.cpp:7: C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: parse error before `&' token C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: syntax error before `&' token C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: parse error before `const' C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: syntax error before `const' C:/boost_1_30_0/boost/python/converter/builtin_converters.hpp:106: parse error before `>' token [... and so on ...] _______________________________________________ C++-sig mailing list C++-sig at python.org http://mail.python.org/mailman/listinfo/c++-sig This message contains information that may be confidential and privileged. Unless you are the addressee (or authorized to receive messages for the addressee), you may not use, copy, or disclose to anyone the message or any information contained in the message. If you have received the message in error, please advise the sender by reply e-mail and delete the message. Nothing in this message should be interpreted as a digital or electronic signature that can be used to authenticate a contract or any other legal document. From alex at glumol.com Tue Aug 5 00:51:48 2003 From: alex at glumol.com (Alex) Date: Tue, 5 Aug 2003 00:51:48 +0200 Subject: [C++-sig] deriving basic python type Message-ID: <005e01c35ada$fd50b0c0$81123951@knar> Hi In python I can do this : class my_int(int): def __rshift__(self, a): #changing the >> operator behavior for example... return self + a The example is quite stupid but is there a way I can make such a class in C++(a class deriving the python int or other python types) then exporting it in python ? a python question: can't we overload the = operator in python ?? -------------- next part -------------- An HTML attachment was scrubbed... URL: From s_sourceforge at nedprod.com Tue Aug 5 00:54:18 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 4 Aug 2003 23:54:18 +0100 Subject: [C++-sig] Re: Boost.Python << & >> bug In-Reply-To: Message-ID: <3F2EF22A.6605.34C725E1@localhost> 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 another 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: Test.cpp Date: 4 Aug 2003, 22:26 Size: 2380 bytes. Type: Program-source -------------- next part -------------- A non-text attachment was scrubbed... Name: Test.cpp Type: application/octet-stream Size: 2380 bytes Desc: not available URL: From s_sourceforge at nedprod.com Tue Aug 5 00:54:18 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 4 Aug 2003 23:54:18 +0100 Subject: [C++-sig] Re: Failure to deduce template argument types In-Reply-To: Message-ID: <3F2EF22A.23828.34C727CC@localhost> On 3 Aug 2003 at 21:12, David Abrahams wrote: > > 15, which is exactly the limit. Is the limit inclusive or exclusive? > > I'll probably find out quicker by recompiling. > > Don't forget that if it's a member function there's a hidden "this" > argument. I knocked it up to 25. Same problem. I thought then, right, let's come at it from the bottom up ie; start with the topmost base class and add those inheriting downwards. I got as far as FXObject (the base class) and guess what, even it won't compile! Currently MSVC7.1 grabs 2Gb of RAM and dies with a failure to allocate more stack. I have no idea what the problem is. I'll play for a day or two more, but time is ticking (everything must be finished by end of August) and I may just have to give up and go for SWIG. I'd been thinking perhaps I could customise pyste to spit out SWIG interface files ... Cheers, Niall From s_sourceforge at nedprod.com Tue Aug 5 00:54:18 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 4 Aug 2003 23:54:18 +0100 Subject: [C++-sig] Re: Boost.Python << & >> bug In-Reply-To: Message-ID: <3F2EF22A.31288.34C72681@localhost> On 3 Aug 2003 at 21:41, David Abrahams wrote: > > Enclosed is the condensed example as requested. > > I assume you're referring to the enclosure in the other message? Yeah my email program mangled it :( > No this is a failure of your wrapping code. Very simply, > > class_< FX::FXId >("FXId", no_init) > .def( other< FX::FXStream >() << self ) > .def( other< FX::FXStream >() >> self ) > > Attempts to wrap two operator expressions which take an FXStream on > the lhs and and FXId on the rhs. But you don't have anything which > would match those expressions. Try it: > > // C++ code > FXStream x; > FXId y; > x << y; // <== error > > friend FX::FXStream& operator<<(FX::FXStream& store,const FXId* > obj){return store;} friend FX::FXStream& operator>>(FX::FXStream& > store,FXId*& obj){return store;} > > These declare operators which take an FXId* on the rhs: > > x << &y; Yeah sorry about that - I had actually corrected this but forgot to recorrect it after another pyste cycle. However if you change the << overload in FXId to take a reference, it's the same problem. See attached. > > Here because FXStream does not provide an overload for anything in > > boost, it can't know it's really an unsigned char. > > I don't know what that means either. I meant that the compiler when faced with "a << b" where there is no direct overload for operator<<(a,b) must cast either a or b to something else to find an overload which can accept them. I had assumed that boost.python provides template class wrapper { ... operator type() const; in order for the wrapper classes to cast down to their containing types so that the overloads provided by the code being wrapped can do their work. Or I suppose the wrapper could also inherit publicly from the wrapped type, but this would probably be less flexible. > The problem you're seeing above may be due to a documentation bug on > my part. These operator wrapping facilities are only suitable for > wrapping operators which work on rvalue arguments. If you want to > wrap your operators which work on non-const lvalues, you should write > something more like: > > FXStream& (FXStream::*pmf)(FXchar&) = &FXStream::operator<<; > > ... > .def('__lshift__', pmf, return_self()); Ok, maybe if I explain what FXStream is: FXStream is like an iostream, or most accurately like QDataStream in Qt. You read and write variables from and to whatever backs it. Therefore usage would be as follows: FXStream s; s << 5; int foo; s >> foo; etc. Can boost.python wrap this sort of usage? > FWIW, Wrapping all these different operators for lots of different > integer types is probably a waste of time because Python only has one > int type. Wrapping overloads on int and ushort, for example, is > redundant. Mmm. This is a problem I was going to tackle eventually. I can't use python's pickle for various reasons so I have to really interface python directly with this. And I most certainly need to write short ints for example. Personally I'd envisage an ideal wrap as exposing as much as possible of the underlying interface. You'd almost certainly never use 85% of it as at a python level you'd keep pretty high-level. But occasionally you would need to get down & dirty, especially if for example the end-user didn't have access to the source. Cheers, Niall From s_sourceforge at nedprod.com Tue Aug 5 00:54:19 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Mon, 4 Aug 2003 23:54:19 +0100 Subject: [C++-sig] Re: Boost.Python << & >> bug In-Reply-To: Message-ID: <3F2EF22B.18831.34C72BF1@localhost> On 3 Aug 2003 at 23:10, David Abrahams wrote: > > FXStream& (FXStream::*pmf)(FXchar&) = &FXStream::operator<<; > > > > ... > > .def('__lshift__', pmf, return_self()); > > Hmm, I could change those wrappers so that the "self" argument was > required to be an lvalue. That would preclude implicit conversions to > the self type from being used, but it would allow the self object to > be mutated by the call. I doubt it would break any real code. > Thoughts from the group? Like it or not, most C++ programmers have never seen the spec and so wouldn't understand what you've just said. My copy is an extremely antiquated 1996 edition which doesn't have function try blocks etc. and while I've read through it several times, I'm still unclear! If I /do/ read you right, wouldn't making self a lvalue preclude auto- casting up to an inherited type? If so in my previous bug report, subclasses of FXId which use its FXStream << & >> overloads when passed as-is would surely no longer work? Also, surely a rvalue can be mutated through calling a non-const method on it? Or does that mean it then becomes a lvalue? Jeesh, I don't know anymore ... Cheers, Niall From nicodemus at globalite.com.br Tue Aug 5 02:19:53 2003 From: nicodemus at globalite.com.br (Nicodemus) Date: Mon, 04 Aug 2003 21:19:53 -0300 Subject: [C++-sig] (Fwd) Previous email to Nicodemus In-Reply-To: <3F2D73FB.18840.2EF1541A@localhost> References: <3F2D73FB.18840.2EF1541A@localhost> Message-ID: <3F2EF829.80803@globalite.com.br> Niall Douglas wrote: >On 3 Aug 2003 at 13:06, Nicodemus wrote: > > >>Yeah, I didn't got this email before. 8) >>Thanks for sending again. >> >> > >It seems then that there's something wrong with email between us. >Maybe your email system thinks I'm spam? ;) > > No, I don't think so... but I'm sure I didn't got it (just searched in my inbox). >>>However, the latest version still has the problem with passing >>>backslashes to Win32 GCCXML. It's GCCXML that barfs (and I got the >>>precompiled binary off its web site). >>> >>> >>Yes, GCCXML expects forward slashes only. Does this trouble you? >> >> > >Absolutely. On Win32 GCCXML dies a very horrible death if there is a >single backslash in its command line. Since pyste takes backslashes >in its input off its command line, this creates a problem eg; me >passing command line variables to pyste which obviously would contain >backslashes. > > I see. No problem, Pyste can be made to convert automatically backslashes to forward slashes. 8) >>Hmm, I see. There's no documentation avaiable for GCCXML, so it is >>kind of a mistery to predict all the weird names that it assigns for >>unnamed enums. 8) Thanks! >> >> > >Not really. GCC itself allocates temporary symbols starting with $. >That's why you can't use $ in your own symbol names on most systems. >You can see plenty more if you investigate the embedded assembler in >GCC. > You are right. Any name starting with $ is certainly an internal name. >>>Next extension: my .pyste file is actually a full blown script which >>>reads the contents of a directory for the header files and then >>>dynamically creates the variable = AllFromHeader(filepath). >>> >>> >>Nice. That's an advantage of they being python scripts. 8) >> >> > >It's why python's great! I haven't had so much fun programming in it >since BBC Basic V on the Acorn Archimedes (a wonderful system for its >day)! A marriage between my C++ and python environments would be >ideal ... at least till I get some time to write the lazy functional >language I've always wanted to write (Haskell's too esoteric). > Yes, I have this feeling too. But the merriage you propose between C++ and Python is already possible: we have been using it with great sucess at our company. >>I see your problem, but I find the solution kind of a "hack". Have you >>tried if sys.path[0] gives the directory where the pyste file is? If >>it doesn't, I think we will have to use this solution, but I prefer >>following the upper-case conventin for constants: >> >> > >Err, doesn't sys.path refer to the script which invoked python? I >think so. Anyway, anything execfile'd is considered not standalone as >far as I understand ie; it merely reads the file into a string and >compiles that to a code object ie; it's no different from exec. >Anyway I've not tried it, and don't have enough experience with >python to say for sure, so I'll shut up now :) > You are right... it was just a guess. I didn't test because I was not at my computer at the time. I guess a variable named INTERFACE_PATH in the pyste file's namespace is good enough then. >class FXTopWindow : public FXWindow // in FXTopWindow.h >{ > FXObject *foo2(); >} > >class FXWindow // in FXWindow.h >{ > FXObject *foo(); >}; > >If I do AllFromHeader on FXTopWindow.h, it pulls in all the base >classes of FXTopWindow (correctly) and then asks for you to set the >return policies of foo() and foo2(). > >Now if I'm also doing FXAllFromHeader on FXWindow.h in the same pyste >file, it'll want a return policy set on foo(). My point is that if >you've already set the policy for foo() in FXWindow, you also set the >policy for all inherited versions of foo() in all subclasses of >FXWindow (because apart from covariant return, return types must stay >identical in overloads in C++). > I couldn't reproduce this problem, actually. If you do an AllFromHeader in FXTopWindow, it should only complain about the lack of policy for FXTopWindow.foo2, since FXWindow won't be exported at that time. In other words, only when a function is about to be exported the check for a policy is made. But if instead of "foo2()" in FXTopWindow you meant "foo()", then I see the problem. 8) Regards, Nicodemus. From s_sourceforge at nedprod.com Tue Aug 5 04:16:02 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 5 Aug 2003 03:16:02 +0100 Subject: Twas a bug in MSVC7.1 (was: Re: [C++-sig] Re: Failure to deduce template argument types) In-Reply-To: <3F2EF22A.23828.34C727CC@localhost> References: Message-ID: <3F2F2172.17493.357FD6F4@localhost> On 4 Aug 2003 at 23:54, Niall Douglas wrote: > I thought then, right, let's come at it from the bottom up ie; start > with the topmost base class and add those inheriting downwards. I got > as far as FXObject (the base class) and guess what, even it won't > compile! Currently MSVC7.1 grabs 2Gb of RAM and dies with a failure to > allocate more stack. I found the problem! If you try compiling the (hopefully this time) attached file on MSVC7.1 it dies horribly as above. The cause? Comment out the anonymous namespace declaration towards the middle of the file. It now compiles perfectly. Nicodemus: In light of this could you fix pyste so that it never generates an unnamed namespace? Is anyone in here friendly with some MS developers? Last time I tried submitting a bug report to MS I had to fill in a dozen forms and open a "support contract". Arse to that ... Cheers, Niall From s_sourceforge at nedprod.com Tue Aug 5 04:16:01 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 5 Aug 2003 03:16:01 +0100 Subject: Twas a bug in MSVC7.1 (was: Re: [C++-sig] Re: Failure to deduce template argument types) In-Reply-To: <3F2EF22A.23828.34C727CC@localhost> References: Message-ID: <3F2F2171.11830.357FD6A4@localhost> 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 another 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: Test2.cpp Date: 5 Aug 2003, 3:15 Size: 1635 bytes. Type: Program-source -------------- next part -------------- A non-text attachment was scrubbed... Name: Test2.cpp Type: application/octet-stream Size: 1635 bytes Desc: not available URL: From s_sourceforge at nedprod.com Tue Aug 5 04:26:48 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 5 Aug 2003 03:26:48 +0100 Subject: [C++-sig] (Fwd) Previous email to Nicodemus In-Reply-To: <3F2EF829.80803@globalite.com.br> References: <3F2D73FB.18840.2EF1541A@localhost> Message-ID: <3F2F23F8.1889.3589B5FC@localhost> On 4 Aug 2003 at 21:19, Nicodemus wrote: > >It's why python's great! I haven't had so much fun programming in it > >since BBC Basic V on the Acorn Archimedes (a wonderful system for its > > day)! A marriage between my C++ and python environments would be > >ideal ... at least till I get some time to write the lazy functional > >language I've always wanted to write (Haskell's too esoteric). > > Yes, I have this feeling too. But the merriage you propose between C++ > and Python is already possible: we have been using it with great > sucess at our company. I've wrapped /easy/ stuff ok and fine. But this library is proving hard. Has anyone tried wrapping the Qt library with boost.python? If so, please let me know - FOX is very like Qt. > >class FXTopWindow : public FXWindow // in FXTopWindow.h > >{ > > FXObject *foo2(); > >} > > > >class FXWindow // in FXWindow.h > >{ > > FXObject *foo(); > >}; > > > >If I do AllFromHeader on FXTopWindow.h, it pulls in all the base > >classes of FXTopWindow (correctly) and then asks for you to set the > >return policies of foo() and foo2(). > > > >Now if I'm also doing FXAllFromHeader on FXWindow.h in the same pyste > > file, it'll want a return policy set on foo(). My point is that if > >you've already set the policy for foo() in FXWindow, you also set the > > policy for all inherited versions of foo() in all subclasses of > >FXWindow (because apart from covariant return, return types must stay > > identical in overloads in C++). > > > > I couldn't reproduce this problem, actually. If you do an > AllFromHeader in FXTopWindow, it should only complain about the lack > of policy for FXTopWindow.foo2, since FXWindow won't be exported at > that time. In other words, only when a function is about to be > exported the check for a policy is made. But if instead of "foo2()" in > FXTopWindow you meant "foo()", then I see the problem. 8) No, because FXWindow::foo() is inherited by FXTopWindow, ie; there is also a FXTopWindow::foo(). My point is that if you tell pyste what FXWindow::foo() returns, it already knows the answer for FXTopWindow:foo() and doesn't need to ask again. Cheers, Niall From dave at boost-consulting.com Tue Aug 5 05:02:57 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 04 Aug 2003 23:02:57 -0400 Subject: [C++-sig] Re: Twas a bug in MSVC7.1 References: <3F2F2172.17493.357FD6F4@localhost> Message-ID: "Niall Douglas" writes: > On 4 Aug 2003 at 23:54, Niall Douglas wrote: > >> I thought then, right, let's come at it from the bottom up ie; start >> with the topmost base class and add those inheriting downwards. I got >> as far as FXObject (the base class) and guess what, even it won't >> compile! Currently MSVC7.1 grabs 2Gb of RAM and dies with a failure to >> allocate more stack. > > I found the problem! If you try compiling the (hopefully this time) > attached file on MSVC7.1 it dies horribly as above. > > The cause? > > Comment out the anonymous namespace declaration towards the middle of > the file. It now compiles perfectly. > > Nicodemus: In light of this could you fix pyste so that it never > generates an unnamed namespace? > > Is anyone in here friendly with some MS developers? Yes; I've forwarded your report on to one of the compiler guys. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Aug 5 05:20:27 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 04 Aug 2003 23:20:27 -0400 Subject: [C++-sig] Re: Boost.Python << & >> bug References: <3F2EF22A.31288.34C72681@localhost> Message-ID: "Niall Douglas" writes: > On 3 Aug 2003 at 21:41, David Abrahams wrote: > >> > Enclosed is the condensed example as requested. >> >> I assume you're referring to the enclosure in the other message? > > Yeah my email program mangled it :( > >> No this is a failure of your wrapping code. Very simply, >> >> class_< FX::FXId >("FXId", no_init) >> .def( other< FX::FXStream >() << self ) >> .def( other< FX::FXStream >() >> self ) >> >> Attempts to wrap two operator expressions which take an FXStream on >> the lhs and and FXId on the rhs. But you don't have anything which >> would match those expressions. Try it: >> >> // C++ code >> FXStream x; >> FXId y; >> x << y; // <== error >> >> friend FX::FXStream& operator<<(FX::FXStream& store,const FXId* >> obj){return store;} friend FX::FXStream& operator>>(FX::FXStream& >> store,FXId*& obj){return store;} >> >> These declare operators which take an FXId* on the rhs: >> >> x << &y; > > Yeah sorry about that - I had actually corrected this but forgot to > recorrect it after another pyste cycle. However if you change the << > overload in FXId to take a reference, it's the same problem. See > attached. That's the same problem we were having before: no support for lvalues. That's now fixed in CVS. You can apply the enclosed patch to try it. -------------- next part -------------- A non-text attachment was scrubbed... Name: operators.patch Type: text/x-patch Size: 2100 bytes Desc: not available URL: -------------- next part -------------- >> > Here because FXStream does not provide an overload for anything in >> > boost, it can't know it's really an unsigned char. >> >> I don't know what that means either. > > I meant that the compiler when faced with "a << b" where there is no > direct overload for operator<<(a,b) must cast either a or b to > something else to find an overload which can accept them. Don't know what you mean by "direct overload". > I had assumed that boost.python provides template class > wrapper { ... operator type() const; in order for the wrapper classes > to cast down to their containing types Huh? Sorry, you lost me. > so that the overloads provided by the code being wrapped can do > their work. Or I suppose the wrapper could also inherit publicly > from the wrapped type, but this would probably be less flexible. None of the above. >> The problem you're seeing above may be due to a documentation bug on >> my part. These operator wrapping facilities are only suitable for >> wrapping operators which work on rvalue arguments. If you want to >> wrap your operators which work on non-const lvalues, you should write >> something more like: >> >> FXStream& (FXStream::*pmf)(FXchar&) = &FXStream::operator<<; >> >> ... >> .def('__lshift__', pmf, return_self()); > > Ok, maybe if I explain what FXStream is: FXStream is like an > iostream I think I figured that out. > , or most accurately like QDataStream in Qt. You read and > write variables from and to whatever backs it. > > Therefore usage would be as follows: > FXStream s; > s << 5; > int foo; > s >> foo; > etc. > > Can boost.python wrap this sort of usage? I just fixed it so that it can. However, you may have trouble with the return type of your operator<<, if it's a reference. There's no provision for using call policies with operators. >> FWIW, Wrapping all these different operators for lots of different >> integer types is probably a waste of time because Python only has one >> int type. Wrapping overloads on int and ushort, for example, is >> redundant. > > Mmm. This is a problem I was going to tackle eventually. I can't use > python's pickle for various reasons so I have to really interface > python directly with this. And I most certainly need to write short > ints for example. You'd better pick a different interface, then, 'cause Python doesn't give you short ints. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Aug 5 05:21:54 2003 From: dave at boost-consulting.com (David Abrahams) Date: Mon, 04 Aug 2003 23:21:54 -0400 Subject: [C++-sig] Re: Boost.Python << & >> bug References: <3F2EF22B.18831.34C72BF1@localhost> Message-ID: "Niall Douglas" writes: > On 3 Aug 2003 at 23:10, David Abrahams wrote: > >> > FXStream& (FXStream::*pmf)(FXchar&) = &FXStream::operator<<; >> > >> > ... >> > .def('__lshift__', pmf, return_self()); >> >> Hmm, I could change those wrappers so that the "self" argument was >> required to be an lvalue. That would preclude implicit conversions to >> the self type from being used, but it would allow the self object to >> be mutated by the call. I doubt it would break any real code. >> Thoughts from the group? > > Like it or not, most C++ programmers have never seen the spec and so > wouldn't understand what you've just said. My copy is an extremely > antiquated 1996 edition which doesn't have function try blocks etc. > and while I've read through it several times, I'm still unclear! Err, lvalue and rvalue are much older concepts than 1996. They come from 'C'. > If I /do/ read you right, wouldn't making self a lvalue preclude > auto- casting up to an inherited type? No, the opposite. > If so in my previous bug report, subclasses of FXId which use its > FXStream << & >> overloads when passed as-is would surely no longer > work? The opposite. > Also, surely a rvalue can be mutated through calling a non-const > method on it? Absolutely not. C++ doesn't let you bind rvalues to non-const references. -- Dave Abrahams Boost Consulting www.boost-consulting.com From romany at actimize.com Tue Aug 5 08:04:39 2003 From: romany at actimize.com (Roman Yakovenko) Date: Tue, 5 Aug 2003 09:04:39 +0300 Subject: [C++-sig] property and documentation Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B00@exchange.adrembi.com> Hi. 1. add_static_property - function of class_ is not referenced in documentation. Nevertheless it works pretty good. 2. How can I specify return value policy for properties ? Thanks. Roman From pierre.barbier at cirad.fr Tue Aug 5 11:28:00 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Tue, 05 Aug 2003 11:28:00 +0200 Subject: [C++-sig] Lates CVS version non compiling Message-ID: <3F2F78A0.1080501@cirad.fr> Hello, I retrieved the latest CVS version of boost using the boost-consulting repository (which is the most accessible). But I have this compilation error : ******************* begin of output ************************************* gcc-C++-action libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/inheritance.o In file included from /home/barbier/apps/boost/boost/graph/breadth_first_search.hpp:37, from libs/python/src/object/inheritance.cpp:8: /home/barbier/apps/boost/boost/graph/graph_concepts.hpp:164: syntax error before `&&' token /home/barbier/apps/boost/boost/graph/graph_concepts.hpp: In member function `void boost::VertexListGraphConcept::constraints()': /home/barbier/apps/boost/boost/graph/graph_concepts.hpp:193: `vertices' not declared /home/barbier/apps/boost/boost/graph/graph_concepts.hpp: In member function `void boost::VertexListGraphConcept::const_constraints(const G&)': /home/barbier/apps/boost/boost/graph/graph_concepts.hpp:206: `vertices' not declared /usr/bin//g++-3.2 -c -Wall -ftemplate-depth-100 -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 -fno-inline -fPIC -I"libs/python/build" -I "/usr/include/python2.2" -I "/home/barbier/apps/boost" -o "libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/inheritance.o" "libs/python/build/../src/object/inheritance.cpp" ...failed gcc-C++-action libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/inheritance.o... ***************************** end of output ********************** ... and I cannot figure out what's the problem ... My g++ version is : $ g++ --version g++ (GCC) 3.2.3 (Debian) Copyright (C) 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 From dave at boost-consulting.com Tue Aug 5 13:01:44 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 07:01:44 -0400 Subject: [C++-sig] Re: property and documentation References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5027B00@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > Hi. > 1. add_static_property - function of class_ is not referenced in documentation. > Nevertheless it works pretty good. Would you like to suggest a documentation patch? > 2. How can I specify return value policy for properties ? Just use make_function explicitly on the get function and your call policy and pass the result on to add_property. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Aug 5 13:23:56 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 07:23:56 -0400 Subject: [C++-sig] Re: Lates CVS version non compiling References: <3F2F78A0.1080501@cirad.fr> Message-ID: Pierre Barbier de Reuille writes: > Hello, I retrieved the latest CVS version of boost using the > boost-consulting repository (which is the most accessible). But I have > this compilation error : > > ******************* begin of output ************************************* > gcc-C++-action > libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/inheritance.o > In file included from > /home/barbier/apps/boost/boost/graph/breadth_first_search.hpp:37, > from libs/python/src/object/inheritance.cpp:8: > /home/barbier/apps/boost/boost/graph/graph_concepts.hpp:164: syntax error > before `&&' token > /home/barbier/apps/boost/boost/graph/graph_concepts.hpp: In member function > `void boost::VertexListGraphConcept::constraints()': > /home/barbier/apps/boost/boost/graph/graph_concepts.hpp:193: `vertices' not > declared > /home/barbier/apps/boost/boost/graph/graph_concepts.hpp: In member function > `void boost::VertexListGraphConcept::const_constraints(const G&)': > /home/barbier/apps/boost/boost/graph/graph_concepts.hpp:206: `vertices' not > declared > > /usr/bin//g++-3.2 -c -Wall -ftemplate-depth-100 > -DBOOST_PYTHON_DYNAMIC_LIB -DBOOST_PYTHON_SOURCE -g -O0 > -fno-inline -fPIC -I"libs/python/build" -I > "/usr/include/python2.2" -I > "/home/barbier/apps/boost" -o > "libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/inheritance.o" > "libs/python/build/../src/object/inheritance.cpp" > > ...failed gcc-C++-action > libs/python/build/bin/libboost_python.so/gcc/debug/runtime-link-dynamic/shared-linkable-true/inheritance.o... > ***************************** end of output ********************** > > ... and I cannot figure out what's the problem ... > My g++ version is : > $ g++ --version g++ (GCC) 3.2.3 (Debian) > Copyright (C) 2002 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It's working for me, though I can't promise that the boost-consulting mirror isn't lagging too far behind. Please try updating again. -- Dave Abrahams Boost Consulting www.boost-consulting.com From pierre.barbier at cirad.fr Tue Aug 5 14:00:17 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Tue, 05 Aug 2003 14:00:17 +0200 Subject: [C++-sig] Re: Lates CVS version non compiling In-Reply-To: References: <3F2F78A0.1080501@cirad.fr> Message-ID: <3F2F9C51.4030105@cirad.fr> David Abrahams wrote: >It's working for me, though I can't promise that the boost-consulting >mirror isn't lagging too far behind. Please try updating again. > > > The update gives nothing new, but I'll see tomorrow if things are better ... hoping the mirror will be mirrored by then :o) -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 From romany at actimize.com Tue Aug 5 14:03:48 2003 From: romany at actimize.com (Roman Yakovenko) Date: Tue, 5 Aug 2003 15:03:48 +0300 Subject: [C++-sig] Re: property and documentation Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF50205FD@exchange.adrembi.com> Yes. class.html is edited file. class_orig.html is file from cvs. If you need also tests in C++ and in Python I can write it. Thanks for the answer. Roman > -----Original Message----- > From: David Abrahams [mailto:dave at boost-consulting.com] > Sent: Tuesday, August 05, 2003 1:02 PM > To: c++-sig at python.org > Subject: [C++-sig] Re: property and documentation > > > "Roman Yakovenko" writes: > > > Hi. > > 1. add_static_property - function of class_ is not > referenced in documentation. > > Nevertheless it works pretty good. > > Would you like to suggest a documentation patch? > > > 2. How can I specify return value policy for properties ? > > Just use make_function explicitly on the get function and your call > policy and pass the result on to add_property. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at boost-consulting.com Tue Aug 5 14:57:55 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 08:57:55 -0400 Subject: [C++-sig] Re: deriving basic python type References: <005e01c35ada$fd50b0c0$81123951@knar> Message-ID: "Alex" writes: > Hi > In python I can do this : > > class my_int(int): > def __rshift__(self, a): #changing the >> operator behavior for example... > return self + a > > The example is quite stupid but is there a way I can make such a > class in C++(a class deriving the python int or other python types) > then exporting it in python ? There's no *easy* way right now, but it's a fairly easy mod to the Boost.Python sources. Gottfried Gan?auge has been working on a patch for another purpose which should make it possible. Gottfried, how's it coming along? -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Aug 5 15:05:35 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 09:05:35 -0400 Subject: [C++-sig] Re: property and documentation References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF50205FD@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > Yes. class.html is edited file. class_orig.html is file from cvs. Well, it isn't fair to simply copy the effects of add_property; they don't have the same semantics. > If you need also tests in C++ and in Python I can write it. Yes, please. A patch to one of the existing tests would probably be best. > Thanks for the answer. > > Roman > >> -----Original Message----- >> From: David Abrahams [mailto:dave at boost-consulting.com] >> Sent: Tuesday, August 05, 2003 1:02 PM >> To: c++-sig at python.org >> Subject: [C++-sig] Re: property and documentation >> >> >> "Roman Yakovenko" writes: >> >> > Hi. >> > 1. add_static_property - function of class_ is not >> referenced in documentation. >> > Nevertheless it works pretty good. >> >> Would you like to suggest a documentation patch? >> >> > 2. How can I specify return value policy for properties ? >> >> Just use make_function explicitly on the get function and your call >> policy and pass the result on to add_property. >> >> -- >> Dave Abrahams >> Boost Consulting >> www.boost-consulting.com >> >> >> _______________________________________________ >> C++-sig mailing list >> C++-sig at python.org >> http://mail.python.org/mailman/listinfo/c++-sig >> > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig -- Dave Abrahams Boost Consulting www.boost-consulting.com From romany at actimize.com Tue Aug 5 18:03:42 2003 From: romany at actimize.com (Roman Yakovenko) Date: Tue, 5 Aug 2003 19:03:42 +0300 Subject: [C++-sig] Re: property and documentation Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF50205FF@exchange.adrembi.com> > Well, it isn't fair to simply copy the effects of add_property; they > don't have the same semantics. 1. There is no difference in function definitions except their names. 2. The difference is Effects: Creates a new Python property class instance, passing object(fget) (and object(fset) in the second form) to its constructor, then adds that property to the Python class with the given attribute name. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^ If you meant smth different, then I don't understand. Also I send you 2 files. I believe that I checked all cases. Also I believe that you will find some things that I will have to fix. (Life is not easy as I'd like to be.) Roman. > -----Original Message----- > From: David Abrahams [mailto:dave at boost-consulting.com] > Sent: Tuesday, August 05, 2003 3:06 PM > To: c++-sig at python.org > Subject: [C++-sig] Re: property and documentation > > > "Roman Yakovenko" writes: > > > Yes. class.html is edited file. class_orig.html is file from cvs. > > Well, it isn't fair to simply copy the effects of add_property; they > don't have the same semantics. > > > If you need also tests in C++ and in Python I can write it. > > Yes, please. A patch to one of the existing tests would probably be > best. > > > Thanks for the answer. > > > > Roman > > > >> -----Original Message----- > >> From: David Abrahams [mailto:dave at boost-consulting.com] > >> Sent: Tuesday, August 05, 2003 1:02 PM > >> To: c++-sig at python.org > >> Subject: [C++-sig] Re: property and documentation > >> > >> > >> "Roman Yakovenko" writes: > >> > >> > Hi. > >> > 1. add_static_property - function of class_ is not > >> referenced in documentation. > >> > Nevertheless it works pretty good. > >> > >> Would you like to suggest a documentation patch? > >> > >> > 2. How can I specify return value policy for properties ? > >> > >> Just use make_function explicitly on the get function and your call > >> policy and pass the result on to add_property. > >> > >> -- > >> Dave Abrahams > >> Boost Consulting > >> www.boost-consulting.com > >> > >> > >> _______________________________________________ > >> C++-sig mailing list > >> C++-sig at python.org > >> http://mail.python.org/mailman/listinfo/c++-sig > >> > > > > > > _______________________________________________ > > C++-sig mailing list > > C++-sig at python.org > > http://mail.python.org/mailman/listinfo/c++-sig > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- A non-text attachment was scrubbed... Name: properties.cpp Type: application/octet-stream Size: 1931 bytes Desc: properties.cpp URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: properties.py Type: application/octet-stream Size: 1145 bytes Desc: properties.py URL: From s_sourceforge at nedprod.com Tue Aug 5 19:16:13 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 5 Aug 2003 18:16:13 +0100 Subject: [C++-sig] const char arrays Message-ID: <3F2FF46D.25651.38B7FB97@localhost> Are const char arrays supported by boost.python? eg; static const char deleteTypeName[]; Obviously we'd prefer them to become python strings. BTW MSVC7.1 here stops with "reference to a zero-sized array is illegal". BTW a full list of what boost.python doesn't support in the docs would be really, really useful - then I can know it's not me misconfiguring something. BTW, I've been trying to find docs on how to implement your own custom converters. Basically I'd like to convert a FXString to a python one automatically and back again. I've come up with: namespace boost { namespace python { BOOST_PYTHON_TO_PYTHON_BY_VALUE(FX::FXString, PyString_FromStringAndSize(x.text(), x.length())) }} // namespace For the other direction I tried: struct FXString_rvalue_from_python { static void init() { slot_rvalue_from_python(); } static unaryfunc *get_slot(PyObject *obj) { return (PyString_Check(obj)) ? &obj->ob_type->tp_str : 0; } static FX::FXString extract(PyObject *intermediate) { return FX::FXString(PyString_AsString(intermediate), PyString_Size(intermediate)); } }; Problem is that slot_rvalue_from_python<> in builtin_converters.hpp is in an unnamed namespace and so therefore is inaccessible to me :( Furthermore, string literals in const char * form don't appear to cast to a FXString first as usual. Instead the compiler treats them as a const char *, which AFAICS Boost.python doesn't support (it seems to not to support any pointer to any basic type actually :( ). This is odd because throughout the header files it /looks/ like it support const literals to python strings, but it sure ain't working here (I get a static assertion failure in make_instance_impl::execute() with is_class::value being value). Any way of working around this? ie; to get const char * literals to become python strings? This library I'm making bindings for works exclusively with C style strings as its lower levels. Cheers, Niall From dave at boost-consulting.com Tue Aug 5 20:02:57 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 14:02:57 -0400 Subject: [C++-sig] Re: const char arrays References: <3F2FF46D.25651.38B7FB97@localhost> Message-ID: "Niall Douglas" writes: > Are const char arrays supported by boost.python? Supported how? > eg; > > static const char deleteTypeName[]; > > Obviously we'd prefer them to become python strings. When? > BTW MSVC7.1 here > stops with "reference to a zero-sized array is illegal". That is correct. The code is ill-formed. This has nothing whatsoever to do with Boost.Python. > BTW a full list of what boost.python doesn't support in the docs > would be really, really useful - then I can know it's not me > misconfiguring something. It would take a long time to write that. It won't wash your socks or > BTW, I've been trying to find docs on how to implement your own > custom converters. Basically I'd like to convert a FXString to a > python one automatically and back again. I've come up with: > > namespace boost { namespace python { > BOOST_PYTHON_TO_PYTHON_BY_VALUE(FX::FXString, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ This macro is not for public consumption; I should probably #undef it at the end of the header file that defines it. > PyString_FromStringAndSize(x.text(), x.length())) > }} // namespace > > For the other direction I tried: > > struct FXString_rvalue_from_python > { > static void init() > { > slot_rvalue_from_python FXString_rvalue_from_python>(); > } > static unaryfunc *get_slot(PyObject *obj) > { > return (PyString_Check(obj)) ? &obj->ob_type->tp_str : 0; > } > static FX::FXString extract(PyObject *intermediate) > { > return FX::FXString(PyString_AsString(intermediate), > PyString_Size(intermediate)); > } > }; > > Problem is that slot_rvalue_from_python<> in builtin_converters.hpp > is in an unnamed namespace and so therefore is inaccessible to me :( I think you should read up on unnamed namespaces again. Anyway, that template is in a source file, for good reason. It's not for public consumption. I suggest you follow the example set in item 2 here: http://www.boost.org/libs/python/doc/v2/faq.html#question2 > Furthermore, string literals in const char * form don't appear to > cast to a FXString first as usual. Instead the compiler treats them > as a const char *, which AFAICS Boost.python doesn't support (it > seems to not to support any pointer to any basic type actually :( > ). It certainly does support char const*, depending on what you mean by "support". This function can be wrapped successfully: char const* f(char const*); You can see that it works from libs/python/test/builtin_converters.* > This is odd because throughout the header files it /looks/ like it > support const literals to python strings, but it sure ain't working > here (I get a static assertion failure in > make_instance_impl::execute() with is_class::value being value). I assume you mean "being false". Clearly you're using an inappropriate call policy such as return_internal_reference or reference_existing_object. > Any way of working around this? ie; to get const char * literals to > become python strings? This library I'm making bindings for works > exclusively with C style strings as its lower levels. There's nothing to work around AFAICT. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Aug 5 20:11:50 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 14:11:50 -0400 Subject: [C++-sig] Re: property and documentation References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF50205FF@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: >> Well, it isn't fair to simply copy the effects of add_property; they >> don't have the same semantics. > 1. There is no difference in function definitions except their >> names. No, one calls base::add_static_property and the other calls base::add_property. > 2. The difference is > > Effects: Creates a new Python property class instance, passing object(fget) (and object(fset) in the second form) to its constructor, then adds that property to the Python class with the given attribute name. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ^^^^^ I'm not sure what you're trying to highlight here, but it doesn't make sense on my screen. > If you meant smth different, then I don't understand. See enclosed. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- > Also I send you 2 files. I believe that I checked all cases. Thanks; I'll add them. > Also I believe that you will find some things that I will have to > fix. (Life is not easy as I'd like to be.) We'll see. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Tue Aug 5 20:13:43 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 14:13:43 -0400 Subject: [C++-sig] Re: property and documentation References: <91BFE89EFFA2904E9A4C3ACB4E5F2DF50205FF@exchange.adrembi.com> Message-ID: "Roman Yakovenko" writes: > Also I send you 2 files. I believe that I checked all cases. > Also I believe that you will find some things that I will have to fix. > (Life is not easy as I'd like to be.) Yup. Please reformulate the python file using doctest or the unittest module. -- Dave Abrahams Boost Consulting www.boost-consulting.com From rwgk at yahoo.com Tue Aug 5 20:35:49 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 5 Aug 2003 11:35:49 -0700 (PDT) Subject: [C++-sig] Re: Lates CVS version non compiling In-Reply-To: <3F2F9C51.4030105@cirad.fr> Message-ID: <20030805183549.98654.qmail@web20203.mail.yahoo.com> The source code bundles published here are based on the Boost CVS from 2003-08-04 20:30 PDT (last night): http://cci.lbl.gov/cctbx_build/show_results.cgi?build_tag=2003_08_04_2056 Unpack cctbx_bundle.selfx and throw away everything but cctbx_sources/boost. The boost tree is untouched. As you will see, compilation worked in nine different configurations under six different operating systems. In addition I've manually verified that all tests in libs/python/test work under redhat80/gcc3.2 (to be more precise: all tests that do not require the unit test library and that are not expected to fail). Ralf --- Pierre Barbier de Reuille wrote: > David Abrahams wrote: > > >It's working for me, though I can't promise that the boost-consulting > >mirror isn't lagging too far behind. Please try updating again. > > > > > > > The update gives nothing new, but I'll see tomorrow if things are better > ... hoping the mirror will be mirrored by then :o) __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From rwgk at yahoo.com Tue Aug 5 20:47:33 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 5 Aug 2003 11:47:33 -0700 (PDT) Subject: [C++-sig] Re: const char arrays In-Reply-To: Message-ID: <20030805184733.43655.qmail@web20206.mail.yahoo.com> --- David Abrahams wrote: > "Niall Douglas" writes: > > Problem is that slot_rvalue_from_python<> in builtin_converters.hpp > > is in an unnamed namespace and so therefore is inaccessible to me :( > > I think you should read up on unnamed namespaces again. Anyway, that > template is in a source file, for good reason. It's not for public > consumption. > > I suggest you follow the example set in item 2 here: > http://www.boost.org/libs/python/doc/v2/faq.html#question2 You may also like to read the three old messages listed under "Custom rvalue converters" near the top of this page: http://cci.lbl.gov/~rwgk/boost_python/ In particular, the third link should be highly relevant. Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From s_sourceforge at nedprod.com Tue Aug 5 21:06:57 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Tue, 5 Aug 2003 20:06:57 +0100 Subject: [C++-sig] Re: const char arrays In-Reply-To: <20030805184733.43655.qmail@web20206.mail.yahoo.com> References: Message-ID: <3F300E61.20282.391D5D6F@localhost> On 5 Aug 2003 at 11:47, Ralf W. Grosse-Kunstleve wrote: > --- David Abrahams wrote: > > "Niall Douglas" writes: > > > Problem is that slot_rvalue_from_python<> in > > > builtin_converters.hpp is in an unnamed namespace and so therefore > > > is inaccessible to me :( > > > > I think you should read up on unnamed namespaces again. Anyway, > > that template is in a source file, for good reason. It's not for > > public consumption. Is it not better I try to solve problems myself before bothering others? I only post here when I really don't know what to do next. > > I suggest you follow the example set in item 2 here: > > http://www.boost.org/libs/python/doc/v2/faq.html#question2 > > You may also like to read the three old messages listed under "Custom > rvalue converters" near the top of this page: > > http://cci.lbl.gov/~rwgk/boost_python/ > > In particular, the third link should be highly relevant. Now /that/ is precisely what I was looking for. Thank you very much! Could not a new section be opened in the docs called "custom rvalue converters"? It seems a waste of time for me to bash my head against a wall and yours to keep answering the same questions over and over. Cheers, Niall From dave at boost-consulting.com Tue Aug 5 21:29:46 2003 From: dave at boost-consulting.com (David Abrahams) Date: Tue, 05 Aug 2003 15:29:46 -0400 Subject: [C++-sig] Re: const char arrays References: <3F300E61.20282.391D5D6F@localhost> Message-ID: "Niall Douglas" writes: > On 5 Aug 2003 at 11:47, Ralf W. Grosse-Kunstleve wrote: > >> --- David Abrahams wrote: >> > "Niall Douglas" writes: >> > > Problem is that slot_rvalue_from_python<> in >> > > builtin_converters.hpp is in an unnamed namespace and so therefore >> > > is inaccessible to me :( >> > >> > I think you should read up on unnamed namespaces again. Anyway, >> > that template is in a source file, for good reason. It's not for >> > public consumption. > > Is it not better I try to solve problems myself before bothering > others? Absolutely, and thanks for that. > I only post here when I really don't know what to do next. You could make it easier for us to help you by posting small examples that demonstrate what you're trying to do and what result you expect, and taking care with the precision of what you write, making sure that you have supplied enough information. I spent 5 minutes wondering why I couldn't find slot_rvalue_from_python in builtin_converters.hpp. If you are unable to convert char const* to python a small reproducible example and a copy of the error message would help. >> > I suggest you follow the example set in item 2 here: >> > http://www.boost.org/libs/python/doc/v2/faq.html#question2 >> >> You may also like to read the three old messages listed under "Custom >> rvalue converters" near the top of this page: >> >> http://cci.lbl.gov/~rwgk/boost_python/ >> >> In particular, the third link should be highly relevant. > > Now /that/ is precisely what I was looking for. Thank you very much! > > Could not a new section be opened in the docs called "custom rvalue > converters"? It seems a waste of time for me to bash my head against > a wall and yours to keep answering the same questions over and over. Sure, we just need a volunteer to write it . -- Dave Abrahams Boost Consulting www.boost-consulting.com From s_sourceforge at nedprod.com Wed Aug 6 05:03:21 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 6 Aug 2003 04:03:21 +0100 Subject: [C++-sig] Re: Boost.Python << & >> bug In-Reply-To: Message-ID: <3F307E09.21178.3AD184A3@localhost> On 4 Aug 2003 at 23:21, David Abrahams wrote: > > Like it or not, most C++ programmers have never seen the spec and so > > wouldn't understand what you've just said. My copy is an extremely > > antiquated 1996 edition which doesn't have function try blocks etc. > > and while I've read through it several times, I'm still unclear! > > Err, lvalue and rvalue are much older concepts than 1996. They come > from 'C'. I know - however the C++ spec defines 99% of the C spec too. What I find interesting is that nowhere in my copy of the spec are lvalue or rvalue defined. I had assumed lvalues are to the left of the equals and rvalues are to the right such that lvalue=rvalue, but (lvalue=rvalue) is a rvalue too. I taught myself C++ from the terse online docs in MSVC4. Some feel that it is terrible there are programmers like me practising out there, but I would argue that I've never been able to afford anything better and few university courses here teach C++. > > If I /do/ read you right, wouldn't making self a lvalue preclude > > auto- casting up to an inherited type? > > No, the opposite. > > > If so in my previous bug report, subclasses of FXId which use its > > FXStream << & >> overloads when passed as-is would surely no longer > > work? > > The opposite. In which case it looks like my definitions of the two are inverted. Hence, your proposal looks like a good idea. I know I've probably sounded really ignorant in these past two emails or so, but if you don't ask questions then you don't realise you're wrong. My apologies if it's annoyed anyone. Cheers, Niall From s_sourceforge at nedprod.com Wed Aug 6 05:03:21 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 6 Aug 2003 04:03:21 +0100 Subject: [C++-sig] Re: Failure to deduce template argument types In-Reply-To: <3F2D7628.3245.2EF9D306@localhost> References: Message-ID: <3F307E09.6830.3AD18601@localhost> On 3 Aug 2003 at 20:52, Niall Douglas wrote: Just for reference if anyone gets that those repeated errors about failing to deduce template arguments, it's because you have an ellipsis in your argument list of at least one method :) So, I guess, I kinda was exceeding the MAX_ARITY after all ... Cheers, Niall From s_sourceforge at nedprod.com Wed Aug 6 05:03:20 2003 From: s_sourceforge at nedprod.com (Niall Douglas) Date: Wed, 6 Aug 2003 04:03:20 +0100 Subject: [C++-sig] Re: const char arrays In-Reply-To: Message-ID: <3F307E08.3651.3AD182F4@localhost> On 5 Aug 2003 at 15:29, David Abrahams wrote: > > Is it not better I try to solve problems myself before bothering > > others? > > Absolutely, and thanks for that. I should add that really I don't know what I'm doing - I'm looking for stuff which seems associated and plugging in new values. My problem is that the terse explanation of each template in the docs doesn't help me see how they all fit together to get the job done. I know that a database of API's is built and through this the binding happens partially at compile-time partially at run-time. eg; below I illustrate a conceptual problem with boost::python::object. > > I only post here when I really don't know what to do next. > > You could make it easier for us to help you by posting small examples > that demonstrate what you're trying to do and what result you expect, > and taking care with the precision of what you write, making sure that > you have supplied enough information. I spent 5 minutes wondering why > I couldn't find slot_rvalue_from_python in builtin_converters.hpp. If > you are unable to convert char const* to python a small reproducible > example and a copy of the error message would help. My problem here is that I'm binding a large library I didn't write and so much stuff depends on other stuff. So I can't just cut & paste the bit I need - I have to alter it which then usually causes a different error report. Hence to get an isolated example takes hours of trial & error :( > > Could not a new section be opened in the docs called "custom rvalue > > converters"? It seems a waste of time for me to bash my head against > > a wall and yours to keep answering the same questions over and over. > > Sure, we just need a volunteer to write it . Ah, but I don't know what I'm doing so that would seem unwise. I'll firstly say (with some joy) that my test class wrapper finally compiled today without error and my thanks to this list for helping me. I've not tried linking yet (bedtime now). A question (and only because of the atlantic clock difference): in the example http://mail.python.org/pipermail/c++-sig/2003- May/004133.html: struct custom_string_to_python_str { static PyObject* convert(custom_string const& s) { return boost::python::incref(boost::python::object(s.value()).ptr()); } }; Isn't this making use of boost.python's inbuilt std::string converter? ie; it's not converting to a python string itself. For some non-std::string based string, would it be more like: struct custom_string_to_python_str { static PyObject* convert(custom_string const& s) { return boost::python::incref(PyString_FromStringAndSize(s.text(), s.length())); } }; I get that boost::python::object encapsulates a python object, and that ptr() returns that object, but I can't see a conversion path in the original without going through std::string (which seems inefficient). Cheers, Niall From rwgk at yahoo.com Wed Aug 6 07:45:33 2003 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Tue, 5 Aug 2003 22:45:33 -0700 (PDT) Subject: [C++-sig] Re: const char arrays In-Reply-To: <3F307E08.3651.3AD182F4@localhost> Message-ID: <20030806054533.88952.qmail@web20209.mail.yahoo.com> --- Niall Douglas wrote: > struct custom_string_to_python_str > { > static PyObject* convert(custom_string const& s) > { > return > boost::python::incref(boost::python::object(s.value()).ptr()); > } > }; > > Isn't this making use of boost.python's inbuilt std::string > converter? ie; it's not converting to a python string itself. Yes. Just to keep the example simple. Or maybe because I was too lazy to figure out the raw C API call. > For some non-std::string based string, would it be more like: > > struct custom_string_to_python_str > { > static PyObject* convert(custom_string const& s) > { > return > boost::python::incref(PyString_FromStringAndSize(s.text(), > s.length())); > } > }; Close, but I think you are leaking a reference count. This should do the job: return PyString_FromStringAndSize(s.text(), s.length()); The bottom line is that you have to return a new Python reference. How exactly you do this is entirely up to you. Ralf __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From skchim0 at engr.uky.edu Wed Aug 6 07:47:56 2003 From: skchim0 at engr.uky.edu (satish k.chimakurthi) Date: Wed, 6 Aug 2003 01:47:56 -0400 Subject: [C++-sig] Python and C++ - Newbie question !! Message-ID: <200308060147.56718.skchim0@engr.uky.edu> Hello all, This is the first time I am posting to this group. I would like to introduce myself as a grad.student at the University Of Kentucky. I hope that most of you have heard of LLNL'S OVERTURE framework (www.llnl.gov/casc/Overture)...which is a framework of huge number of C++ LIBRARIES, useful for grid generation and other purposes Using OVERTURE'S FRAMEWORK OF CLASSES, I have written a small program for my application and obviously my code is written in C++ since OVERTURE itself is entirely in C++. I declare a number of objects in my code using the standard classes that are defined in OVERTURE FRAMEWORK. In order to run my code in OVERTURE, I would need to make it using a Makefile which contains all the rules needed to link the code to the OVERTURE framework. However, I need to do the same thing from python. I would like to use python as an input mechanism to this code and would like to make it in the Overture framework from Python. The python module that we generate to do this should be in a position to understand the functionality of all the classes which are defined somewhere in the software but whose objects are declared in the code that we write in OVERTURE. Can someone tell me how I can go about this ?? I am really confused with all the documentation that is there... Thanks a lot for your help in advance, SATISH -- SATISH K.CHIMAKURTHI GRAD. RESEARCH ASSISTANT UNIVERSITY OF KENTUCKY LEXINGTON KENTUCKY STATE From pierre.barbier at cirad.fr Wed Aug 6 10:05:12 2003 From: pierre.barbier at cirad.fr (Pierre Barbier de Reuille) Date: Wed, 06 Aug 2003 10:05:12 +0200 Subject: [C++-sig] Re: Lates CVS version non compiling In-Reply-To: <20030805183549.98654.qmail@web20203.mail.yahoo.com> References: <20030805183549.98654.qmail@web20203.mail.yahoo.com> Message-ID: <3F30B6B8.6060200@cirad.fr> The boost version you gave me is indeed working fine, but the CVS one on boost-consulting.com is still not compiling. I'll try a check-out on sourceforge ... Ralf W. Grosse-Kunstleve wrote: >The source code bundles published here are based on the Boost CVS from >2003-08-04 20:30 PDT (last night): > >http://cci.lbl.gov/cctbx_build/show_results.cgi?build_tag=2003_08_04_2056 > >Unpack cctbx_bundle.selfx and throw away everything but cctbx_sources/boost. >The boost tree is untouched. > >As you will see, compilation worked in nine different configurations under six >different operating systems. In addition I've manually verified that all tests >in libs/python/test work under redhat80/gcc3.2 (to be more precise: all tests >that do not require the unit test library and that are not expected to fail). > >Ralf > > > -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77 fax : (33) 4 67 61 56 68 From benny at kramekweb.com Wed Aug 6 12:54:18 2003 From: benny at kramekweb.com (Benny Kramek) Date: Wed, 6 Aug 2003 13:54:18 +0300 Subject: [C++-sig] Inheriting a Python class from a C++ class Message-ID: <20030806135418.1ab0f296.benny@kramekweb.com> Hi, this is my first message here. This is what I would like to do: an abstract class in c++ a python class inherits from this class python code calls a c++ function that takes as an argument an instance of the c++ abstract base class Here is a simple code example of what I tried //--- animal.cpp --- #include using namespace boost::python; class Animal { public: virtual void sleep(int hours) = 0; }; class AnimalWrap : public Animal { public: AnimalWrap(PyObject* self_) : self(self_) {} void sleep(int hours) { return call_method(self, "sleep"); } PyObject* self; }; void checkAnimal(Animal* animal) { // ... } BOOST_PYTHON_MODULE(animal) { class_("Animal", no_init) ; def("checkAnimal", checkAnimal); } //--- animal.cpp --- # --- baboon.py --- import animal class Baboon(animal.Animal): def __init__(self): pass def sleep(self, hours): print 'sleeping' george = Baboon() animal.checkAnimal(george) # --- baboon.py --- when I execute baboon.py I get the following error: Traceback (most recent call last): File "baboon.py", line 11, in ? animal.checkAnimal(george) TypeError: bad argument type for built-in operation I also tried changing the checkAnimal c++ function to take a reference as an argument instead of a pointer, but i get the same error. Thank you, Benny Kramek From prabhu at aero.iitm.ernet.in Wed Aug 6 13:11:21 2003 From: prabhu at aero.iitm.ernet.in (Prabhu Ramachandran) Date: Wed, 6 Aug 2003 16:41:21 +0530 Subject: [C++-sig] Python and C++ - Newbie question !! In-Reply-To: <200308060147.56718.skchim0@engr.uky.edu> References: <200308060147.56718.skchim0@engr.uky.edu> Message-ID: <16176.57945.949490.391246@monster.linux.in> Hi, >>>>> "SKC" == satish k chimakurthi writes: [snip] SKC> However, I need to do the same thing from python. I would SKC> like to use python as an input mechanism to this code and SKC> would like to make it in the Overture framework from SKC> Python. The python module that we generate to do this should SKC> be in a position to understand the functionality of all the SKC> classes which are defined somewhere in the software but whose SKC> objects are declared in the code that we write in OVERTURE. SKC> Can someone tell me how I can go about this ?? You'll need to wrap parts of the Overture library to Python and this will require quite a bit of effort initially. You only need to wrap parts that you intend to use. Once you wrap the libraries to Python you can use Overture from Python. You can use Boost.Python or SWIG to generate the Python wrappers. You'll need to read the respective tutorials/manuals, start with the small examples, get familiar and then go on to try and wrap Overture itself. >From what I can tell of Overture this is not going to be a trivial project. Good luck! cheers, prabhu From dave at boost-consulting.com Wed Aug 6 13:29:48 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 06 Aug 2003 07:29:48 -0400 Subject: [C++-sig] Re: INTERFACING C++ TO PYTHON In-Reply-To: <200308060048.46134.skchim0@engr.uky.edu> (satish k. chimakurthi's message of "Wed, 6 Aug 2003 00:48:46 -0400") References: <200308060048.46134.skchim0@engr.uky.edu> Message-ID: "satish k.chimakurthi" writes: > Dear sir, > > I am a grad.student at the UNIVERSITY OF KENTUCKY. This mail is with reference > to "Boost.python" that I have come across recently Hi Satish, Please take your Boost.Python questions to the C++-sig: http://www.boost.org/mailing_lists.htm#cplussig > I am basically a newbie in python. In my research I need to use > LLNL'S "Overture-ogen C++ software framework" for grid generation. > > I wrote a small code for my application using this huge C++ > framework which is I can run this code within the "Overture > framework" using standard rules for making which I have in a > Makefile > > However, I would want to use PYTHON to do the samething and would > like to glue my C++ code to python so that I can use python not only > as an input mechanism to this code, but also run my code in the > OVERTURE FRAMEWORK, but from outside. In short, I would like to > provide an interface to this C++ framework so that I can access the > various features of the framework by mere manipulation of my > underlying C++ code that I would write. > > Can I use Boost.python to do this ?? Probably. If I understand you correctly, that's what Boost.Python is made for. > Can you cite any references to learn more about this ?? Did you read the documentation at http://www.boost.org/libs/python? > Thanks in advance for your time and patience, > > With Best Regards, > > Satish I'm happy to help. > -- > SATISH K.CHIMAKURTHI > GRAD. RESEARCH ASSISTANT > UNIVERSITY OF KENTUCKY > LEXINGTON > KENTUCKY STATE > -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Aug 6 13:43:20 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 06 Aug 2003 07:43:20 -0400 Subject: [C++-sig] Re: const char arrays References: <3F307E08.3651.3AD182F4@localhost> <20030806054533.88952.qmail@web20209.mail.yahoo.com> Message-ID: "Ralf W. Grosse-Kunstleve" writes: > --- Niall Douglas wrote: >> struct custom_string_to_python_str >> { >> static PyObject* convert(custom_string const& s) >> { >> return >> boost::python::incref(boost::python::object(s.value()).ptr()); >> } >> }; >> >> Isn't this making use of boost.python's inbuilt std::string >> converter? ie; it's not converting to a python string itself. > > Yes. Just to keep the example simple. Or maybe because I was too lazy to figure > out the raw C API call. Err, no. Trace it in a debugger; the conversion should not go through std::string at all. If it does I'm very surprised. >> For some non-std::string based string, would it be more like: >> >> struct custom_string_to_python_str >> { >> static PyObject* convert(custom_string const& s) >> { >> return >> boost::python::incref(PyString_FromStringAndSize(s.text(), >> s.length())); >> } >> }; > > Close, but I think you are leaking a reference count. This should do the job: > > return PyString_FromStringAndSize(s.text(), s.length()); > > The bottom line is that you have to return a new Python reference. > How exactly you do this is entirely up to you. On the other hand, Ralf's instincts were good; it's generally better to use high-level Boost.Python calls than low-level Python 'C' API calls. When the converter mechanism is ready for us to document, it will probably not be returning raw PyObject*s. -- Dave Abrahams Boost Consulting www.boost-consulting.com From dave at boost-consulting.com Wed Aug 6 13:47:37 2003 From: dave at boost-consulting.com (David Abrahams) Date: Wed, 06 Aug 2003 07:47:37 -0400 Subject: [C++-sig] Re: Inheriting a Python class from a C++ class References: <20030806135418.1ab0f296.benny@kramekweb.com> Message-ID: Benny Kramek writes: > Hi, this is my first message here. > > This is what I would like to do: > > an abstract class in c++ > a python class inherits from this class > python code calls a c++ function that takes as an argument an instance > of the c++ abstract base class > > Here is a simple code example of what I tried > > //--- animal.cpp --- > > #include > > using namespace boost::python; > > class Animal > { > public: > virtual void sleep(int hours) = 0; > }; > > class AnimalWrap : public Animal > { > public: > AnimalWrap(PyObject* self_) : self(self_) {} > void sleep(int hours) { return call_method(self, "sleep"); } > PyObject* self; > }; > > void checkAnimal(Animal* animal) > { > // ... > } > > BOOST_PYTHON_MODULE(animal) > { > class_("Animal", no_init) ^^^^^^^ You have to eliminate this. > ; > > def("checkAnimal", checkAnimal); > } > > //--- animal.cpp --- > > # --- baboon.py --- > > import animal > > class Baboon(animal.Animal): > def __init__(self): > pass and ^^^^^^^^^^^^^^^^^^^ this. Your Baboon class must contain an Animal class somewhere, or it will never be able to be passed where an Animal* is expected. You can also def __init__(self): animal.Animal.__init__(self) of course. > def sleep(self, hours): > print 'sleeping' > > george = Baboon() > > animal.checkAnimal(george) > > # --- baboon.py --- > > when I execute baboon.py I get the following error: > > Traceback (most recent call last): > File "baboon.py", line 11, in ? > animal.checkAnimal(george) > TypeError: bad argument type for built-in operation > > I also tried changing the checkAnimal c++ function to take a > reference as an argument instead of a pointer, but i get the same > error. > > Thank you, > Benny Kramek -- Dave Abrahams Boost Consulting www.boost-consulting.com From romany at actimize.com Wed Aug 6 14:19:01 2003 From: romany at actimize.com (Roman Yakovenko) Date: Wed, 6 Aug 2003 15:19:01 +0300 Subject: [C++-sig] Re: property and documentation Message-ID: <91BFE89EFFA2904E9A4C3ACB4E5F2DF5020600@exchange.adrembi.com> Done. If this version is not good for you I will fix it too. Thanks for good library. Roman > -----Original Message----- > From: David Abrahams [mailto:dave at boost-consulting.com] > Sent: Tuesday, August 05, 2003 8:14 PM > To: c++-sig at python.org > Subject: [C++-sig] Re: property and documentation > > > "Roman Yakovenko" writes: > > > Also I send you 2 files. I believe that I checked all cases. > > Also I believe that you will find some things that I will > have to fix. > > (Life is not easy as I'd like to be.) > > Yup. Please reformulate the python file using doctest or the > unittest module. > > -- > Dave Abrahams > Boost Consulting > www.boost-consulting.com > > > _______________________________________________ > C++-sig mailing list > C++-sig at python.org > http://mail.python.org/mailman/listinfo/c++-sig > -------------- next part -------------- A non-text attachment was scrubbed... Name: properties.py Type: application/octet-stream Size: 1562 bytes Desc: properties.py URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: properties.cpp Type: application/octet-stream Size: 1931 bytes Desc: properties.cpp URL: