Mailman 3 December 2004 - Cplusplus-sig

Re: what happened with this std::string parameter inboost.python
by Donnie Leen Dec. 24, 2004

Dec. 24, 2004

Another problem(maybe) I found while boost.python deal with std::string: // my function void write1( std::string s ) { // no nothing } // my class to deal with python error output class Cout { public: std::string sbuf; public: void write( std::string s ) { sbuf += s; if ( sbuf.find_first_of( "\n" ) == std::string::npos ) return; printf( "Cout::write\t%s", sbuf.c_str() ); sbuf = ""; } }; I wrapped it by boost.python in my c++ program embedding boost.python, BOOST_PYTHON_MODULE(mym) { def( "write", &write1 ); class_<Cout>( "Cout", init<std::string>() ) .def_readwrite( "sbuf", &Cout::sbuf ) .def( "write", &Cout::write ) ; } and then I call it as following: PyRun_SimpleString( "import mym\n" "import sys\n" "sys.stderr = mym.Cout('')\n" "mym.write('aa','bb')\n" ); it crashed, I can't caught any exception, even I insert the contents of libs/python/test/module_tail.cpp into my program. Donnie Leen

2 6

Re: what happened with this std::string parameter inboost.python
by Donnie Leen Dec. 20, 2004

Dec. 20, 2004

Dave Abrahams wrote: >What do you mean by "crashed?" Are you sure it didn't throw an >exception that was never caught? yes, I try to catch the exception, but it crashed in the function PyRun_SimpleString I called to run python code,and it didn't throw exception to my try-catch. >I suggest you insert the contents of libs/python/test/module_tail.cpp >into your program, run it again, and see where the JIT debugger says the >"crash" occurs. > >I also suggest you try putting the logic of your program inside a call >to python::handle_exception, per libs/python/test/embedding.cpp: > > if (python::handle_exception(something)) > { > if (PyErr_Occurred()) > PyErr_Print(); > return 1; > } Thanks your suggestion, I had followed you suggestion, but I didn't get any more information about the "crash", the result was the same as the first time I run it. I made the c++ program in vc6, use stlport std library, my system is win2000+sp4. and in the vc6 debugger, i found the exception was caught by the following function in src/object/function.cpp of boost.python: static PyObject * function_call(PyObject *func, PyObject *args, PyObject *kw) { PyObject* result = 0; handle_exception(bind_return(result, static_cast<function*>(func), args, kw)); return result; } I use PyRun_SimpleString to run python code, and the python code call my function through function_call of boost.python, the function_call had handled the exception, could I catch the exception any more? I paste the call stack of vc6 debugger as following: NTDLL! 77f813b1() NTDLL! 77fb6972() NTDLL! 77f8be26() KERNEL32! 77e7f76e() _CrtIsValidHeapPointer(const void * 0x005857b0) line 1697 _free_dbg_lk(void * 0x005857b0, int 1) line 1044 + 9 bytes _free_dbg(void * 0x005857b0, int 1) line 1001 + 13 bytes free(void * 0x005857b0) line 956 + 11 bytes operator delete(void * 0x005857b0) line 7 + 9 bytes _STL::__stl_delete(void * 0x005857b0) line 99 + 33 bytes _STL::__node_alloc<1,0>::deallocate(void * 0x005857b0, unsigned int 414) line 253 + 42 bytes _STL::allocator<char>::deallocate(char * 0x005857b0, unsigned int 414) line 360 + 19 bytes _STL::_STLP_alloc_proxy<char *,char,_STL::allocator<char> >::deallocate(char * 0x005857b0, unsigned int 414) line 507 _STL::_String_base<char,_STL::allocator<char> >::_M_deallocate_block() line 124 + 58 bytes _STL::_String_base<char,_STL::allocator<char> >::~_String_base<char,_STL::allocator<char> >() line 135 + 65 bytes _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >::~basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >() line 302 + 96 bytes boost::python::detail::value_destroyer<0>::execute(const _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > * 0x0012f8c4) line 34 boost::python::detail::destroy_referent_impl(void * 0x0012f8c4, _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & (void)* 0x00000000) line 95 + 9 bytes boost::python::detail::destroy_referent(void * 0x0012f8c4, _STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > & (void)* 0x00000000) line 101 + 11 bytes boost::python::converter::rvalue_from_python_data<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > &>::~rvalue_from_python_data<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > &>() line 135 + 14 bytes boost::python::converter::arg_rvalue_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >::~arg_rvalue_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >() + 37 bytes boost::python::arg_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >::~arg_from_python<_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> > >() + 37 bytes boost::python::detail::caller_arity<1>::impl<void (__cdecl*)(_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >),boost::python::default_call_policies,boost::mpl::vector2<void,_STL::basic_string<char,_STL::char_traits<char>,_STbfdc5a11(_object * 0x00a81c90, _object * 0x00000000) line 201 + 42 bytes boost::python::objects::caller_py_function_impl<boost::python::detail::caller<void (__cdecl*)(_STL::basic_string<char,_STL::char_traits<char>,_STL::allocator<char> >),boost::python::default_call_policies,boost::mpl::vector2<void,_STL::basic_stringf77a00c5(_object * 0x00a81c90, _object * 0x00000000) line 39 boost::python::objects::py_function::operator()(_object * 0x00a81c90, _object * 0x00000000) line 139 + 32 bytes boost::python::objects::function::call(_object * 0x00a81c90, _object * 0x00000000) line 212 + 36 bytes boost::python::objects::`anonymous namespace'::bind_return::operator()() line 505 + 25 bytes boost::detail::function::void_function_obj_invoker0<boost::python::objects::`anonymous namespace'::bind_return,void>::invoke(boost::detail::function::any_pointer {...}) line 129 boost::function0<void,int>::operator()() line 320 + 28 bytes boost::python::handle_exception_impl(boost::function0<void,int> {...}) line 26 boost::python::handle_exception(boost::python::objects::`anonymous-namespace'::bind_return {...}) line 29 + 35 bytes function_call(_object * 0x00564a80, _object * 0x00a81c90, _object * 0x00000000) line 537 + 56 bytes PYTHON24! 1e01937c() Thanks Donnie Leen

2 1

RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
by Greg Copeland Dec. 20, 2004

Dec. 20, 2004

Thanks for the follow up. I'm aware of the Red Hat debacle, however, the "2.96" compiler I'm using, isn't even from a Linux vendor. As such, downgrading or upgrading to the compiler is not an easy solution, so I'm told. I must admit that I'm regurgitating what I've been told and can't vouch for validity of, however, I'm told that the vendor has some custom patches being applied against "their" compiler and will not release them. Worse, I'm also told that key components of their software will not compile with some of gnu's newer compiler releases. End result, we're fairly stuck. I'm still exploring some other options (alternate compiler [non-gnu] provided by vendor), so hopefully this won't prove to be tar pit too. Cheers, Greg Copeland > -----Original Message----- > From: c++-sig-bounces(a)python.org [mailto:c++-sig-bounces@python.org] On > Behalf Of Daryle Walker > Sent: Monday, December 20, 2004 4:18 AM > To: Python/C++ Integration Development > Subject: Re: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks > > On 12/17/04 2:40 PM, "Greg Copeland" <GCopeland(a)efjohnson.com> wrote: > > > Ya, that's what I feared. I've heard (unconfirmed) that one vendor's > > 2.96 may very well be different from another vendor's 2.96 release. > > Your comment seems to confirm it. > > [There may be some flaming in this post.] > > As I understand it, there was _never_ an official GCC 2.96 release. The > GNU > group uses a system where all version numbers ending in an even digit are > exclusively non-final (i.e. alpha/beta) and all version numbers ending in > an > odd digit are exclusively final. After an odd-number release, the > intermediate version in CVS immediately gets renamed to an even number, > then > further work is done, then a rename to an odd number precedes the next > release (and the cycle continues). > > Certain vendors (e.g. Red Hat) plucked out the GCC code out of CVS at some > random point after 2.95 and stuck it on their CDs. This suckered many > uninformed users into compiling with beta software. For you, either > downgrade to 2.95 or upgrade to any of the 3.x releases. And tell all of > your friends to do the same. Sorry, but the definition of "GCC 2.96" is > too > unstable for any developer to reliably help you. > > Red Hat, and any others, should apologize to all of their users for being > inattentive and hoisting this problem on the users. And apologize to all > the developers, like me, who have to "waste" time to educate everyone > about > the mistake. (Worse, Red Hat picked an intermediate version whose line > died > without ever having a final release. So users have to pick either an > older > version without fixed bugs or do a major reorganization for jumping to a > new > compiler line.) > > > >> -----Original Message----- > >> From: c++-sig-bounces(a)python.org [mailto:c++-sig-bounces@python.org] On > >> Behalf Of Ralf W. Grosse-Kunstleve > >> Sent: Friday, December 17, 2004 1:24 PM > >> To: Development of Python/C++ integration > >> Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks > >> > >> --- Greg Copeland <GCopeland(a)efjohnson.com> wrote: > >> > >>> What type of problems did you encounter? Can you describe the types > of > >>> "workarounds" that you had to implement? Did you encounter any > problems > >>> using boost/operators.hpp? Did you get complaints about template > default > >>> arguments...etc...? > >> > >> No, this doesn't ring any bells. The problems I had were much more > subtle. > >> > >> I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves > differently > >> than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet > another > >> variety that calls itself gcc 2.96? > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT hotmail DOT com > > _______________________________________________ > C++-sig mailing list > C++-sig(a)python.org > http://mail.python.org/mailman/listinfo/c++-sig

1 0

RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
by Greg Copeland Dec. 20, 2004

Dec. 20, 2004

Ya, that's what I feared. I've heard (unconfirmed) that one vendor's 2.96 may very well be different from another vendor's 2.96 release. Your comment seems to confirm it. Thanks for speaking up! Cheers, Greg Copeland > -----Original Message----- > From: c++-sig-bounces(a)python.org [mailto:c++-sig-bounces@python.org] On > Behalf Of Ralf W. Grosse-Kunstleve > Sent: Friday, December 17, 2004 1:24 PM > To: Development of Python/C++ integration > Subject: RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks > > --- Greg Copeland <GCopeland(a)efjohnson.com> wrote: > > > What type of problems did you encounter? Can you describe the types of > > "workarounds" that you had to implement? Did you encounter any problems > > using boost/operators.hpp? Did you get complaints about template > > default arguments...etc...? > > No, this doesn't ring any bells. The problems I had were much more subtle. > > I noticed that the gcc 2.96 that comes with Red Hat 7.1 behaves > differently > than the gcc 2.96 that comes with Red Hat 7.3. Maybe you have yet another > variety that calls itself gcc 2.96? > > Ralf > > > > > __________________________________ > Do you Yahoo!? > Yahoo! Mail - 250MB free storage. Do more. Manage less. > http://info.mail.yahoo.com/mail_250 > _______________________________________________ > C++-sig mailing list > C++-sig(a)python.org > http://mail.python.org/mailman/listinfo/c++-sig

2 1

RE: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks
by Greg Copeland Dec. 17, 2004

Dec. 17, 2004

What type of problems did you encounter? Can you describe the types of "workarounds" that you had to implement? Did you encounter any problems using boost/operators.hpp? Did you get complaints about template default arguments...etc...? Cheers, Greg Copeland > -----Original Message----- > From: c++-sig-bounces+gcopeland=efjohnson.com(a)python.org [mailto:c++-sig- > bounces+gcopeland=efjohnson.com(a)python.org] On Behalf Of Ralf W. Grosse- > Kunstleve > Sent: Thursday, December 16, 2004 9:47 PM > To: Development of Python/C++ integration > Subject: Re: [C++-sig] Boost, Boost.Python and G++ 2.96 on VxWorks > > --- Greg Copeland <GCopeland(a)efjohnson.com> wrote: > > > Is there anyone currently using this compiler with Boost.Python? > > I am using the gcc 2.96 that comes with Red Hat 7.3. I had to come up with > a > few workarounds but I am not aware of major problems. > > Ralf > > > > > __________________________________ > Do you Yahoo!? > All your favorites on one personal page - Try My Yahoo! > http://my.yahoo.com > _______________________________________________ > C++-sig mailing list > C++-sig(a)python.org > http://mail.python.org/mailman/listinfo/c++-sig

2 1

code generation problems
by James Mastro Dec. 17, 2004

Dec. 17, 2004

I am having a big problem with BPL. When my extension module is compiled by bjam I think it is giving me bad code. I have a couple of functions in a C++ object that have almost the same signature, just slightly different names. I have a free function in the extension module for each of these that calls into the C++ object: MyObject* gObject; void DoSomethingToObject( int data ) { gObject->DoSomething( data ); } void SomethingElseToObject( int data ) { gObject->SomethingElse( data ); } gObject is a valid ptr. When this code executes, the gObject->DoSomething call actually calls gObject->SomethingElse and vise versa! So I went and changed names thinking maybe it was confused by similar names, that didn't help. I went as far as to add some bogus parameters to SomethingElse but even that did not work. It still happily calls the wrong function even though it was called with a different number of parameters. Now I don't trust the VS debugger at all, but as I step through the code everything seems to make sense. It's executing the code it's stepping through, it's not just displaying the wrong lines of code as it has done before for me. The 2 free functions that are called from Python get called fine. They're called by other C++ code not related to my module and it works fine. It's just the call into gObject that is bad from the wrapped free functions. If you ignore the fact that it's calling a function with different number of parameters and filling those in with garbage, even after the bogus call everything is working OK until an assertion of mine fails because the wrong function has been called at the wrong time. The gObject class looks just fine to me. Calling some other gObject member functions instead works fine. It's just the DoSomething and SomethingElse ones that are problematic. Thinking I probably had bad code elsewhere or something I moved the calls to these 2 free functions up so they're basically the first things called by the Python script, but I get the same result. Are there any known problems with compiling modules that would lead to something like this? I don't even know where to start. I guess I will have to try to come up with a small example demonstrating the problem. This is using boost 1.32 with vc-7_1. -jim

2 4

Boost, Boost.Python and G++ 2.96 on VxWorks
by Greg Copeland Dec. 17, 2004

Dec. 17, 2004

I'm attempting to compile Boost (3.1.1) and especially Boost.Python against Python 2.3.4 on VxWorks. I have done so, without problem, via cygwin (g++ 3.3.3). So, I know the version of python isn't the problem. The compiler provided by WRS, to use for VxWorks, is g++ 2.96 (ya, I know). I did a number of searches and found that some portions of Boost are said not to compile with this compiler, however, I found a message from Dave Abrahams, in August 2003, who said that this compiler is supported with Boost.Python. Is this still the case? Should I reasonably expect Boost & Boost.Python to compile using this compiler? Is there anyone currently using this compiler with Boost.Python? Best Regards, Greg Copeland

2 1

[Boost] [Graph] Problem compiling on Solaris 10
by Johan Carlstedt Dec. 16, 2004

Dec. 16, 2004

Hello, I am having problems compiling Boost 1.32 on Solaris 10 X86 with gcc 3.4.1 and Python 2.23. The compilation fails for libboost_python with the error message below. I have tried with and without "-fpermissive". I would be grateful if anyone was able to advice. With friendly regards, Johan Carlstedt bash-2.05b# bjam "-sTOOLS=gcc" "-sGXX=g++ -fpermissive" install ....found 11612 targets... ....updating 32 targets... gcc-C++-action bin/boost/libs/python/build/libboost_python.so/gcc/debug/shared-linkable- true/inheritance.o In file included from /export/home/johan/boost_1_32_0/libs/python/build/../src/object/inherit ance.cpp:11: /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error: expected identifier before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:441: error: expected `>' before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `VP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `EP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `GP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `EL' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: type/value mismatch at argument 3 in template parameter list for `template<class OutEdgeListS, class VertexListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> class boost::adjacency_list' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: expected a type, got `3' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 4 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 5 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 6 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: template argument 7 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:444: error: `Tag' has not been declared /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: error: expected `,' or `...' before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: warning: ISO C++ forbids declaration of `g' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:445: warning: ISO C++ forbids declaration of `Value' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: In function `void boost::set_property(int&, int, int)': /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: `m_property' has not been declared /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: request for member of non-aggregate type before ',' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: warning: there are no arguments to `Tag' that depend on a template parameter, so a declaration of `Tag' must be available /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: `value' undeclared (first use this function) /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:446: error: (Each undeclared identifier is reported only once for each function it appears in.) /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp: At global scope: /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error: expected identifier before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:449: error: expected `>' before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `VP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `EP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `GP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `EL' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: type/value mismatch at argument 3 in template parameter list for `template<class OutEdgeListS, class VertexListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> class boost::adjacency_list' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: expected a type, got `3' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 4 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 5 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 6 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 7 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: `Tag' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 1 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: template argument 2 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: expected init-declarator before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:452: error: expected `;' before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error: expected identifier before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: warning: ISO C++ forbids declaration of `parameter' with no type /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:457: error: expected `>' before numeric constant /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `VP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `EP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `GP' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `EL' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: type/value mismatch at argument 3 in template parameter list for `template<class OutEdgeListS, class VertexListS, class DirectedS, class VertexProperty, class EdgeProperty, class GraphProperty, class EdgeListS> class boost::adjacency_list' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: expected a type, got `3' /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 4 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 5 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 6 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 7 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: `Tag' was not declared in this scope /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 1 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: template argument 2 is invalid /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: expected init-declarator before '&' token /export/home/johan/boost_1_32_0/boost/graph/adjacency_list.hpp:461: error: expected `;' before '&' token

2 1

Disallow adding attributes to wrapped classes from Python
by haller＠ableton.com Dec. 15, 2004

Dec. 15, 2004

Is there a way to make the __dict__ of exposed classes read-only? I fear it will be a common error for Python programmers to make typos when setting attributes, and I would like this to generate an error rather than silently adding a new attribute. class_<Foo>("Foo") .add_property("foobar", &Foo::getFooBar, &Foo::setFooBar) ; >>> foo.foobaz = 7 # oops: typo! >>> foo.foobaz 7 -- Stefan Haller Ableton http://www.ableton.com/

3 7

problems with weak_ptr to python object
by Arthur Peters Dec. 14, 2004

Dec. 14, 2004

Hello, I am working on a project that uses shared_ptr for more or less everything, so weak_ptrs are important. I discovered that the shared_ptrs created by boost.python from python objects that use shared_ptr as a holder are not shared_ptrs managing the same object as the holder, but are shared_ptrs managing a reference to the python object. This is fine until you make a weak_ptr to it. Then the weak_ptr will become invalid way before the actually object is destroyed. See the thread from a year ago called "keeping weak_ptrs upon python objects smart_ptrholders" (http://mail.python.org/pipermail/c++-sig/2003-November/006337.html). There was talk of fixing this problem. Did it go anywhere? I have had the following thoughts: The problem is that a shared_ptr directly related (sharing a use_count) to the holder is only passed to C++ if the type requested exactly matches the holder (I think). And in other cases, a unrelated (seperate use_count) shared_ptr to the same object is passed. If a shared_ptr<void> was used in place of the void*s in the converter code the shared_ptr-ness could be preserved. It would be silly to use shared_ptr<void> when the target type was a plain pointer so maybe it would be possible to make a duplicate of a part of the "conversion path" that used shared_ptr<void>. This path could be used by shared_ptr_from_python to return shared_ptrs that are related to the shared_ptr that is the holder. Does any of that make sense? I'm having trouble explaining my self. Thanks, -Arthur

2 1