[C++-sig] Re: Re: Boost.Python v2: beginning of generalized object support
daveh at cadlink.com
Tue Jun 18 01:15:10 CEST 2002
"David Abrahams" <david.abrahams at rcn.com> wrote in message
news:01f801c21640$c348ee90$6601a8c0 at boostconsulting.com...
> What's wrong with just ensuring that the object contains an lvalue of T?
> > I'm not sure how else a class can get wrapped and
> > still be safely manipulated through it pointer.
> There are examples in libs/python/test/m1.cpp. Imagine you wanted to work
> with some extension type from a non-Boost.Python module.
> > If it can't then we may as well just use a plain object anyway.
> It can, though. Besides being more-general, my code is so much simpler and
> exploits existing facilities...
I see what you mean from the sample. I didn't consider the possibility of 2
co-operating modules, one boost, one not, though not sure how often this
would occur in practice.
> > and
> > result in an unnecessary data member for the default case.
> What data member?
The T* m_ptr which would not be required for the default object<>.
> > In any case I
> > think that operator* and operator-> should be replaced by a simple
> > function, as I often just land up doing &*my_object to get a PyObject
> > pointer anyway and an access function would be much clearer.
> Yes, I was trolling for name suggestions for this function. I don't like
> get() because that traditionally acccesses the same thing as operator->(),
> and the derived lvalue_ptr-thing will cover the get() function with its
> own, which accesses something else.
Maybe something like get_native(), native_ptr() or just native().
It would also be useful to be able to extract the handle<> directly somehow
(return the private handle<> instance).
> > > Also, the name for this thing should end in _ptr, since it is a
> > > smart pointer. What should the first part of the name be?
> > I'm not that keen on lvalue_ptr as it is not particularly explicit.
> Me neither.
If verbosity is not important then there is class_obj_ptr.
> > If it
> > derives from object it will also contain its functionality also
> > will be interesting!)
> I'm not sure it's all that useful. Perhaps the derivation from object
> such a hot plan after all, and I should do the small amount of extra
> implementation work implied by making it a non-derived class.
Maybe, as there isn't to much of the object functionality that's really
useful for a class instance besides attributes.
> > , but object_ptr could be misconstrued. I'm not much
> > help here, what else could (or should) this ptr contain besides an
> > class instance, maybe that will give some more hints for a name.
> It will hold a Python object which can be converted to (and thus contains)
> an lvalue of type T. That's why I chose "lvalue_ptr".
More information about the Cplusplus-sig