Re: [C++-sig] Boost.Python indexing suite version 2?
The documentation points out (with very good reason) that just using
"::with_policies(bp::return_internal_reference)" can cause major
problems if the container in question reallocates things between the
time that you extract the object and the time you try to access it.
v = VectorofFoo()
v.extend([Foo() for x in range(10)])
f = v[5] #returns a reference to a foo on the heap
f.extend([Foo() for x in range(1000)]) #almost certainly causes
reallocation of underlying array in c++
f.function() #accesses a no longer valid reference, sky falls.
The standard indexing suite uses clever proxy magic to work around this.
On second Look, it looks like the intended usage of container_proxy is
something like this:
class_< container_proxy > >("class_< std::vector
>("VectorOfFoo") )
.def( indexing::container_suite< container_proxy >
>() )
;
Which seems kind of clunky to me.
I think defaulting to by-value is the wrong behavior. The idiom
"v[n].some_attribute = blah" works seamlessly on python lists, and c++
vectors. The indexing suite V1 is the default behavior, and can be
disabled if needed.
I am using container_suite on a "std::map >" and the only problem I have is a compiler
warning about a very long decorated name. using foo_vector_exposer_t
directly seems kind of clunky to me.
While I was trying to use indexing suite v2 to wrap a non-STL but
STL-like container class, I noticed that the documentation for doing so
is badly out of date. This is the main (almost the only) advantage that
V2 has over V1, so these docs badly need to be updated.
-Original Message-
From:
cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@python.org
[mailto:cplusplus-sig-bounces+matthew.scouten=tradingtechnologies@py
thon.org] On Behalf Of Roman Yakovenko
Sent: Saturday, July 25, 2009 2:19 PM
To: Development of Python/C++ integration
Subject: Re: [C++-sig] Boost.Python indexing suite version 2?
On Thu, Jul 23, 2009 at 6:59 PM, Matthew Scouten
(TT) wrote:
> This is a sketch of what I want to do. This seems to work seamlessly
> with the
> included indexing suite. I cannot figure out how the make it work with
> the advanced one.
Okey. By default the indexing suite v2 returns objects by value (
default call policy ).
It is very simple to change this behavior:
namespace bp = boost::python;
typedef bp::class_< std::vector< foo > > foo_vector_exposer_t;
foo_vector_exposer_t foo_vector_exposer =
foo_vector_exposer_t( "foo_vector");
bp::scope foo_vector_scope( foo_vector_exposer );
foo_vector_exposer.def( bp::indexing::vector_suite<
std::vector< foo > >::with_policies(bp::return_internal_reference<
>()) );
And than all your code will work as expected.
I suggest you not to use "container_suite":
* the compilation is longer
* it is also unable to guess/resolve between map and multimap
containers.
P.S. Let me know if you still want\need to use container_proxy. I
never used that class, so it could take me some time to understand it.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Boost.Python module initialization failure
What is the right way to report error from the Boost.Python extension module init function? Gennadiy ___ Cplusplus-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Boost.Python indexing suite version 2?
On Mon, Jul 27, 2009 at 7:29 PM, Matthew Scouten
(TT) wrote:
> The documentation points out (with very good reason) that just using
> "::with_policies(bp::return_internal_reference)" can cause major
> problems if the container in question reallocates things between the
> time that you extract the object and the time you try to access it.
>
> v = VectorofFoo()
> v.extend([Foo() for x in range(10)])
> f = v[5] #returns a reference to a foo on the heap
> f.extend([Foo() for x in range(1000)]) #almost certainly causes
> reallocation of underlying array in c++
>
> f.function() #accesses a no longer valid reference, sky falls.
>
> The standard indexing suite uses clever proxy magic to work around this.
>
Okey, that is why v2 provides container_proxy class. There is an
advantage of not mixing "proxy magic" with container suite: simple
implementation.
>From my experience, this limitation was never a problem. After all,
users understands that they deal with wrapper and should be careful.
>
> On second Look, it looks like the intended usage of container_proxy is
> something like this:
>
> class_< container_proxy > >("class_< std::vector
>>("VectorOfFoo") )
> .def( indexing::container_suite< container_proxy >
>>() )
> ;
>
> Which seems kind of clunky to me.
I don't think the author had a choice here. Can you propose an
alternative interface?
One possible solution is to add helper function: ( pseudo code)
template< class TContainer >
void register_container_proxy( const char* name, boost::type< TContainer > ){
class_< container_proxy < TContainer > >( name )
.def( indexing::container_suite< container_proxy < TContainer > >>() ) ;
}
> I think defaulting to by-value is the wrong behavior. The idiom
> "v[n].some_attribute = blah" works seamlessly on python lists, and c++
> vectors. The indexing suite V1 is the default behavior, and can be
> disabled if needed.
May be it is a little bit confusing, but
>> The documentation points out (with very good reason) that just using
>> "::with_policies(bp::return_internal_reference)" can cause major
>> problems if the container in question reallocates things between the
>> time that you extract the object and the time you try to access it.
makes it reasonable and consistent.
>
> I am using container_suite on a "std::map std::vector >" and the only problem I have is a compiler
> warning about a very long decorated name. using foo_vector_exposer_t
> directly seems kind of clunky to me.
You can write the code as you wish. I like this way, mainly because it
is easier to understand a compiler errors. At least it points you
exactly to the problematic line. The syntax
class_ < ... >
.def (...)
.def (...);
is cool but it has its price.
> While I was trying to use indexing suite v2 to wrap a non-STL but
> STL-like container class, I noticed that the documentation for doing so
> is badly out of date. This is the main (almost the only) advantage that
> V2 has over V1, so these docs badly need to be updated.
You are welcome to contribute. My English and explanation skills are
not as good as I want.
--
Roman Yakovenko
C++ Python language binding
http://www.language-binding.net/
___
Cplusplus-sig mailing list
[email protected]
http://mail.python.org/mailman/listinfo/cplusplus-sig
