Boost logo

Boost :

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

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at