Raoul Gough <RaoulGough@[...].uk>  writes:

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

OK, good point.

> > 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?

Can't do that without providing a new_reference(...) wrapper.

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

Interesting sig.  Do you want me to `C-x C-e' it?

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


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