Re: [boost] [function types][review]

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
function because 

  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
generalization.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com