Tobias Schwinger <tschwinger@neoscientists.org> 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