[C++-sig] Re: (no subject)

[Raoul Gough]

David Abrahams <dave at boost-consulting.com> writes:

> Raoul Gough <RaoulGough at yahoo.co.uk> writes:
[snip]
>> Using this approach would cause me to worry about object slicing (C++
>> object slicing, I mean) since I would probably tend to pass and
>> certainly return reference objects by value. I suppose the base class
>> would actually be equipped to handle everything internally, but I
>> would *usually* assume that the following code is wrong:
>>
>> reference make_python_object () {
>>   return new_reference (/*...*/);  // Slices object on return
>> }
>
> There's nothing wrong with "slicing".  Its dangers are vastly
> overrated.  Think of it as an implicit conversion operator.

I don't think I overrate the dangers of slicing - they are real and
should be considered when slicing happens. Pass or return by value
could be totally wrong, depending on the implementation details. For
instance, assume that ~reference() does nothing, and only
~new_reference() does a Py_DECREF. This would be a workable
implementation, and would mean that borrowed_reference doesn't have to
increment the reference count to compensate for the base class
destructor. Unfortunately, returning the base-class part of a
new_reference object would then delete the target object
immediately. I guess my point is that without investigating further,
somebody reading the code can't tell if the slicing is benign or not.

Of course, any experienced C++ programmer chooses return by value
vs. by smart pointer "automatically" depending on the situation - thus
neatly avoiding the potential problems.

>> The overloaded constructor approach has the advantage that it makes it
>> clear that the type of the constructed object is the same whatever the
>> original source of the raw pointer.
>
> Well, my point was that I thought it was more useful and safer to
> encode the acquisition method in the type.
>
> Could be wrong, though.

It also seems safer to me, since the base class constructor is
protected. On the other hand, maybe removing the plain pointer
overload for handle<>::handle() would be just as good?

-- 
Raoul Gough.
(setq dabbrev-case-fold-search nil)