[C++-sig] Re: Re: Boost.Python v2: beginning of generalized object support

[Dave Hawkes]

"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
access
> > 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
classic
> > > 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
> (operators
> > will be interesting!)
>
> I'm not sure it's all that useful. Perhaps the derivation from object
isn't
> 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
> extension
> > 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".
>

OK

Dave Hawkes