[re-post with the correct from-address, the original got rejected] On 01/23/2013 07:08 PM, Michael Wild wrote: > On 01/23/2013 07:03 PM, Jim Bosch wrote: >> On 01/23/2013 12:56 PM, Michael Wild wrote: >> >> <snip> >> >>> >>> Yes, I thought of that too. While this "solves" this case (it certainly >>> is not very discoverable for future maintainers), it does not help in >>> the case of container support. Say I wanted to expose >>> std::vector<QString> (or std::vector<ustom_string> from the Boost.Python >>> FAQ, for that matter) using the boost::python::vector_indexing_suite. I >>> am perfectly able to create such a list, I can append items, the only >>> thing I can't do is *retrieving* them. It's like a black hole for data >>> ;-) >>> >> >> I'm afraid the vector_indexing_suite is some black magic I'm not >> terribly familiar with. But I do know that in some contexts it returns >> proxy objects in order to allow setting and safer lifetime management, >> and I suspect that's what is not playing nicely with your custom >> converters. Or have you investigated that further and determined that >> it's calling make_getter, and that's why you're focused on that? > > Not at all, I just stumbled across this problem a little later than the > one with the make_getter. Somehow I suspect that if I can teach bp to > properly return by value, both cases would be resolved automagically. > After all, things work smoothly for std::string. > > Michael >
About the indexing_suite: By setting the NoProxy template argument to true, the custom string is being converted correctly, leaving me only with make_getter to be dealt with. For now I think I'll go with explicitly specializing make_getter. AFAIK this does no harm and automagically fixes class_::add_property() and friends. Thanks for all the input. Michael _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
