David Abrahams <dave@[...].com>  writes:

>  Raoul Gough <RaoulGough@[...].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)


_______________________________________________
C++-sig mailing list
C++-sig@[...].org
http://mail.python.org/mailman/listinfo/c++-sig