Re: [C++-sig] [pybindgen] references?
On Tuesday 04 November 2008 01:18:47 Alan Baljeu wrote: > void baz(foo &x); > > If I have a foo, I call baz with it, foo's contents may change but it's > still the same object. I don't see an issue here, unless foo is a smart > pointer type. Sometimes, baz might store the reference (admittedly, that's not very good design, except for some register_xxx functions, but I'd use pointers then anyway), and when the foo is destroyed, you have a dangling reference. In boost::python, this can be prevented, by binding the lifetime of foo to some other objects (where baz stores the reference). Greetings, Hans ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [pybindgen] references?
2008/11/4 Alan Baljeu <[EMAIL PROTECTED]>
> Glad to read this here. I agree with you about the dislike thing. I can't
> stand auto_ptr, and if I had to give an object control over the life of
> another object I would generally choose a shared_ptr protocol. I mean, the
> object existed fine before passing it in. Why can't it survive independent
> of its new owner?
>
> On the binding side of things, it's good to know pybindgen supports this.
> I really think the documentation needs an overhaul. I find reference
> manuals too hard to use for learning an API. The front page of the
> reference (which I nearly overlooked) has a good tutorial but it's quite
> incomplete. In fact, if I wasn't aesthetically predisposed to choosing this
> solution, or if you didn't answer my questions all timely-like, I would have
> given up. Yet it's looking more and more like it's a nearly comprehensive
> (and elegant) solution so I'm glad to stick with it.
>
Well, I'm sure you'll find a pybindgen limitation sooner or later :-) As
you would with any other tool... But I have developed pybindgen mostly
oriented to the features I needed to bind NS-3[1].
Regarding documentation, you are right. I would never condemn anyone for
not using pybindgen due to lack of documentation, but I'm afraid I don't
have time or predisposition for writing good documentation. The little
tutorial documentation there is not even written by me, Mathieu Lacage wrote
it (or most of it). Otherwise, pybindgen can still be useful for
programmers with enough patience to work with incomplete documentation, and
that's why I make it available anyway. If you find it useful, good for you,
if not, I understand.
[1] http://www.nsnam.org/
>
>
> --
>
> I know that you're thinking about the custodian_and_ward policy of
> boost.python, but pybindgen also supports it. For example:
>
> class SomeObject
> {
> [...]
> Foobar* get_foobar_with_self_as_custodian ();
> Foobar* get_foobar_with_other_as_custodian (const SomeObject *other);
> void set_foobar_with_self_as_custodian (Foobar *foobar);
> };
>
>
> Is wrapped by pybindgen code:
>
> SomeObject = mod.add_class('SomeObject', allow_subclassing=True)
>[...]
> SomeObject.add_method('get_foobar_with_self_as_custodian',
> retval('Foobar*', custodian=0), [])
> SomeObject.add_method('get_foobar_with_other_as_custodian',
> retval('Foobar*', custodian=1),
> [param('SomeObject*', 'other',
> transfer_ownership=False)])
> SomeObject.add_method('set_foobar_with_self_as_custodian',
> retval('void'),
> [param('Foobar*', 'foobar', custodian=0)])
>
> [excerpt from the pybindgen unit tests]
>
> Although I personally dislike this sort of practice; I would hate working
> with APIs this complicated even in C++.
>
> --
> Gustavo J. A. M. Carneiro
> INESC Porto, Telecommunications and Multimedia Unit
> "The universe is always one step beyond logic." -- Frank Herbert
>
> --
> Instant message from any web browser! Try the new * Yahoo! Canada
> Messenger for the Web
> BETA*
>
> ___
> Cplusplus-sig mailing list
> Cplusplus-sig@python.org
> http://mail.python.org/mailman/listinfo/cplusplus-sig
>
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] mutable object has bogus __hash__
I have a bunch of classes in c++ with operator== defined, and I exported it as __eq__. They apparently inherited object's __hash__ . All was well until my users started to put these objects in sets and use them as dict keys. Objects that have the compare equal do not have the same hash. This causes weirdness and errors. I would like to have the __hash__ not exist. These objects are mutable and should NOT be used as keys. Is there a way to hide it? If I have them throw NotImplemented will python do something sensible with that? I suppose the other thing I could do is come up with some bull hash function, but I would rather not. The objects really do not belong in sets or dict keys. ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] Contructor with "with_custodian_and_ward_postcall"
Hi
To solve my previous problem I'm trying implement a class witch store
the PyObject pointer.
using this solution:
http://www.boost.org/doc/libs/1_36_0/libs/python/doc/v2/faq.html#xref
then during the destructor of my wrapper class I want destroy the
PyObjects of my children with:
object_wrapper::~object_wrapper()
{
foreach(object child, this->children())
python::detail::dealloc(child->py_self;);
}
but after my function I get a core dump in this boost call:
* boost::python::objects::find_instance_impl(_object*,
boost::python::type_info, bool) (in
/usr/lib/libboost_python-py25.so.1.35.0)
I think there is a way to communicate to boost to remove my objet form
your object list. How I can do this?
This is the correct way?? Have a best boost way to do this??
BR
--
Renato Araujo Oliveira Filho
On Mon, Nov 3, 2008 at 4:15 PM, Renato Araujo <[EMAIL PROTECTED]> wrote:
> Sorry my last message I sent incomplete :)
>
>
> I will try again.
>
> First I have a c++ class like this:
>
> struct object
> {
> object(object *parent=0) // if parent !=NULL append this at
> parent children list
> ~object() //Destroy all children
> };
>
>
> Is possible implement this using "python::with_custodian_and_ward_postcall"?
> I tried some like that:
>
> qclass_ ("object", python::init<> ())
> //here i put self will be the ward and arg 2 (parent) will be the
> custodian
> //the lifetime of the self will be dependent on the lifetime of the parent
>
> .def(python::init()[python::with_custodian_and_ward_postcall<2,1>()])
>
>
> But in my python code I tried some like that:
>
> o = object()
> o2 = object(o)
>
> del o
>
> and this produce this exception during the del operation:
> *** glibc detected *** python: free(): invalid pointer: 0x09c89970 ***
>
--
Renato Araujo Oliveira Filho
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] mutable object has bogus __hash__
I would like to have the __hash__ not exist. These objects are mutable and should NOT be used as keys. Is there a way to hide it? If I have them throw NotImplemented will python do something sensible with that? Python raises a TypeError for unhashable things: >>> [1,2,3].__hash__() Traceback (most recent call last): File "", line 1, in TypeError: list objects are unhashable (You get the same with hash([1,2,3]) of course.) Alex ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] mutable object has bogus __hash__
I looks at what it would take to write proper hash functions. These classes have ridiculously complicated equality operators. I am going to throw a type error and any users who don't like it can bite me. Thanks guys. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] thon.org] On Behalf Of Alex Mohr Sent: Tuesday, November 04, 2008 11:19 AM To: Development of Python/C++ integration Subject: Re: [C++-sig] mutable object has bogus __hash__ > I would like to have the __hash__ not exist. These objects are mutable > and should NOT be used as keys. Is there a way to hide it? If I have > them throw NotImplemented will python do something sensible with that? Python raises a TypeError for unhashable things: >>> [1,2,3].__hash__() Traceback (most recent call last): File "", line 1, in TypeError: list objects are unhashable (You get the same with hash([1,2,3]) of course.) Alex ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
[C++-sig] Using destructors in the right way
Hi all, I'm using boost::python to make bindings and now I got in trouble. I'm trying to avoid Python deleting my C++ class before other classes but I didn't find any clue on how to do this. Is there a way to tell boost that my object should be the last one to be deleted? Thanks in advance! Regards, Luciano ___ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [pybindgen] references?
Glad to read this here. I agree with you about the dislike thing. I can't
stand auto_ptr, and if I had to give an object control over the life of another
object I would generally choose a shared_ptr protocol. I mean, the object
existed fine before passing it in. Why can't it survive independent of its new
owner?
On the binding side of things, it's good to know pybindgen supports this. I
really think the documentation needs an overhaul. I find reference manuals too
hard to use for learning an API. The front page of the reference (which I
nearly overlooked) has a good tutorial but it's quite incomplete. In fact, if
I wasn't aesthetically predisposed to choosing this solution, or if you didn't
answer my questions all timely-like, I would have given up. Yet it's looking
more and more like it's a nearly comprehensive (and elegant) solution so I'm
glad to stick with it.
--
I know that you're thinking about the custodian_and_ward policy of
boost.python, but pybindgen also supports it. For example:
class SomeObject
{
[...]
Foobar* get_foobar_with_self_as_custodian ();
Foobar* get_foobar_with_other_as_custodian (const SomeObject *other);
void set_foobar_with_self_as_custodian (Foobar *foobar);
};
Is wrapped by pybindgen code:
SomeObject = mod.add_class('SomeObject', allow_subclassing=True)
[...]
SomeObject.add_method('get_foobar_with_self_as_custodian',
retval('Foobar*', custodian=0), [])
SomeObject.add_method('get_foobar_with_other_as_custodian',
retval('Foobar*', custodian=1),
[param('SomeObject*', 'other',
transfer_ownership=False)])
SomeObject.add_method('set_foobar_with_self_as_custodian', retval('void'),
[param('Foobar*', 'foobar', custodian=0)])
[excerpt from the pybindgen unit tests]
Although I personally dislike this sort of practice; I would hate working with
APIs this complicated even in C++.
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
__
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now at
http://ca.toolbar.yahoo.com.___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
Re: [C++-sig] [pybindgen] references?
2008/11/3 Stefan Seefeld <[EMAIL PROTECTED]>
> Alan Baljeu wrote:
>
>> I just read the tutorial page on pybindgen, but it doesn't talk about
>> reference types. 99% of my C++ code involves passing around things like
>> foo&, so this is significant to me. How is it done?
>>
>>
>
> If you need fine-grained control about argument passing policies (as soon
> as you need reference-semantics, you have to be careful about lifetime
> management, for example), you are better off writing boost.python bindings
> manually, I would suggest.
I know that you're thinking about the custodian_and_ward policy of
boost.python, but pybindgen also supports it. For example:
class SomeObject
{
[...]
Foobar* get_foobar_with_self_as_custodian ();
Foobar* get_foobar_with_other_as_custodian (const SomeObject *other);
void set_foobar_with_self_as_custodian (Foobar *foobar);
};
Is wrapped by pybindgen code:
SomeObject = mod.add_class('SomeObject', allow_subclassing=True)
[...]
SomeObject.add_method('get_foobar_with_self_as_custodian',
retval('Foobar*', custodian=0), [])
SomeObject.add_method('get_foobar_with_other_as_custodian',
retval('Foobar*', custodian=1),
[param('SomeObject*', 'other',
transfer_ownership=False)])
SomeObject.add_method('set_foobar_with_self_as_custodian',
retval('void'),
[param('Foobar*', 'foobar', custodian=0)])
[excerpt from the pybindgen unit tests]
Although I personally dislike this sort of practice; I would hate working
with APIs this complicated even in C++.
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
___
Cplusplus-sig mailing list
Cplusplus-sig@python.org
http://mail.python.org/mailman/listinfo/cplusplus-sig
