Re: [C++-sig] Define class in 2 scopes without re-exposing
On 15/04/12 03:23, Dave Abrahams wrote:
You can't do this; don't even try. Each C++ class has to have a unique
Python identity. If you just want to refer to the same class by a
different name, you can of course:
BOOST_PYTHON_MODULE( _sandbox )
{
namespace bp = ::boost::python;
object inner;
{
bp::scope scope = bp::class_< Outer1>( "Outer1" );
inner = bp::class_< Inner>( "Inner" );
}
{
object outer2 = bp::class_< Outer2>( "Outer2" );
outer2.attr("Inner") = inner;
}
}
I didn't know you could do that and it is useful but it is not quite
what I had in mind. I would rather not pass the inner object around all
the parts of my code that might need it. Is it possible to get it out of
the registry in the second block? I'm guessing it must be in there
somewhere as I get exactly the same behaviour (plus the warning message)
if I just register the class in both blocks.
Thanks,
John.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Define class in 2 scopes without re-exposing
On 04/16/2012 03:15 AM, John Reid wrote:
On 15/04/12 03:23, Dave Abrahams wrote:
You can't do this; don't even try. Each C++ class has to have a unique
Python identity. If you just want to refer to the same class by a
different name, you can of course:
BOOST_PYTHON_MODULE( _sandbox )
{
namespace bp = ::boost::python;
object inner;
{
bp::scope scope = bp::class_< Outer1>( "Outer1" );
inner = bp::class_< Inner>( "Inner" );
}
{
object outer2 = bp::class_< Outer2>( "Outer2" );
outer2.attr("Inner") = inner;
}
}
I didn't know you could do that and it is useful but it is not quite
what I had in mind. I would rather not pass the inner object around all
the parts of my code that might need it. Is it possible to get it out of
the registry in the second block? I'm guessing it must be in there
somewhere as I get exactly the same behaviour (plus the warning message)
if I just register the class in both blocks.
You can get it from the registry (see below), but it requires relying on
what I'd consider implementation details of the library.
If you can, I'd recommend just importing the module that contains outer1
and doing the above trick with that:
bp::object mod1 = bp::import("module1");
bp::object outer2 = bp::class_< Outer2 >("Outer2");
outer2.attr("Inner") = mod1.attr("Outer1").attr("Inner");
If you do really want to use the registry, I think you want something
like this:
bp::converter::registration const * reg =
bp::converter::registry::query(bp::type_id());
assert(reg); // 0 if you haven't wrapped Inner yet
bp::object inner(bp::handle<>(bp::borrowed(
reinterpret_cast(reg.get_class_object())
)));
Jim
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Define class in 2 scopes without re-exposing
on Mon Apr 16 2012, John Reid wrote:
> On 15/04/12 03:23, Dave Abrahams wrote:
>>
>> You can't do this; don't even try. Each C++ class has to have a unique
>> Python identity. If you just want to refer to the same class by a
>> different name, you can of course:
>>
>
>> BOOST_PYTHON_MODULE( _sandbox )
>> {
>> namespace bp = ::boost::python;
>> object inner;
>> {
>> bp::scope scope = bp::class_< Outer1>( "Outer1" );
>> inner = bp::class_< Inner>( "Inner" );
>> }
>>
>> {
>> object outer2 = bp::class_< Outer2>( "Outer2" );
>> outer2.attr("Inner") = inner;
>> }
>> }
>>
>
> I didn't know you could do that and it is useful but it is not quite
> what I had in mind. I would rather not pass the inner object around
> all the parts of my code that might need it. Is it possible to get it
> out of the registry in the second block?
Why don't you read to the end of my posting? The answer's there at the
bottom :-)
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Define class in 2 scopes without re-exposing
On 16/04/12 19:13, Dave Abrahams wrote:
>
> on Mon Apr 16 2012, John Reid wrote:
>
>> On 15/04/12 03:23, Dave Abrahams wrote:
>>>
>>> You can't do this; don't even try. Each C++ class has to have a unique
>>> Python identity. If you just want to refer to the same class by a
>>> different name, you can of course:
>>>
>>
>>> BOOST_PYTHON_MODULE( _sandbox )
>>> {
>>> namespace bp = ::boost::python;
>>> object inner;
>>> {
>>> bp::scope scope = bp::class_< Outer1>( "Outer1" );
>>> inner = bp::class_< Inner>( "Inner" );
>>> }
>>>
>>> {
>>> object outer2 = bp::class_< Outer2>( "Outer2" );
>>> outer2.attr("Inner") = inner;
>>> }
>>> }
>>>
>>
>> I didn't know you could do that and it is useful but it is not quite
>> what I had in mind. I would rather not pass the inner object around
>> all the parts of my code that might need it. Is it possible to get it
>> out of the registry in the second block?
>
> Why don't you read to the end of my posting? The answer's there at the
> bottom :-)
>
Thanks! I was guilty of reading your post too quickly. And thx to Jim
too for what looks like a similar method.
John.
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Assign ownership of Python-constructed object to C++ runtime
I am pondering trying to eliminate some usages of shared pointers in my code since I have finally completed enough of it that I have good ownership rules for things in place. I still have one spot, which is basically the main door to the C++ runtime, where I have a problem. I've been creating instances of some objects in Python, with the purpose of assigning to another object for safekeeping. Really that other object is what I have in mind for managing everything about these objects--including their runtimes. But I see the objects get destroyed when the Python declaration for them go out of scope. That would normally be the right thing. I'm trying to think of alternatives. The best I can think of is to use a static factory method instead that returns an internal reference. I'm intend to experiment with that now but I am wondering if there are some other things to consider instead. Inevitably somebody will ask why I'm doing away with the shared pointers. I have some cycles due to communication that means a lot of stuff never actually gets deleted due to the reference-counting methodology in them. When I used weak references, I found they were getting deleted too eagerly. And by this point, I otherwise have gotten an ownership hierarchy down. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
