From: David Abrahams (dave_at_[hidden])
Date: 2005-06-18 08:00:53
Tobias Schwinger <tschwinger_at_[hidden]> writes:
> Dave's point is (I hope I summarize this accurately, please correct me if not)
> to put the class type into the sequence of parameters adding (cv-qualifications
> - but we all agree on this
I must've missed when that happened
> - and) a reference to it.
I think so.
> I, however, am not convinced this is an improvement: While this may
> unify things in some cases it makes things more difficult in others
> (considering the case where we want a "this pointer" and not a
> reference, for example).
I can only explain the reasons I chose a reference and not a pointer
in the context of Boost.Python: pointers can be null, but references
cannot, and you can never call a member function on a null pointer.
In Python, the closest thing to a null pointer is called None, and
Boost.Python allows None to be converted into a null pointer of any
type when calling from Python.
You can add methods to the Python view of a wrapped C++ class'
interface by wrapping free functions. When setting up a free function
to be bound into a wrapped C++ class X, you give it a first parameter
of X& so that the type system will only allow the function to be
entered with legitimate X instances.
Incidentally, we use X& and not X const& even when it's a const member
a. Python only has a notion of immutability, not constness.
b. An argument of type of X const& uses an "rvalue converter" that
admits one layer of implicit conversions before the function is
called. By contrast, the lifetime of Python object within which
an X& is matched will always persist past the call.
Many of these considerations are very specific to Boost.Python,
obviously. You'd have to think about the most appropriate
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk