Greg Colvin wrote:

> In article <009A0A5CE1159CC0.49802F14@ittpub.nl> "Wil Evers" <wil@ittpub.nl>:
> >What I definitely do not understand is why the new auto_ptr template
> >doesn't even allow us to query if it is actually owning the object
> >pointed to.

> I found it very hard to contrive examples where is_owner() would
> actually be useful.

I agree with Greg here: any code that is intended to execute
differently, depending on the value returned by putative member
auto_ptr<>::is_owner(), is just bad code.

I can imagine:

  auto_ptr<T> p1;
  auto_ptr<T> p2 = new T;
  if (...) {
     p1 = p2;
  }
  // what to do here?

The answer is: it's your responsibility to keep track of ownership
of pointers; if you can't do it manually, then automate it with
reference counting or something.  That's not what auto_ptr<> is for;
its purpose is to make sure that the value "new T" gets destroyed.
It does that job perfectly; don't ask it to do your job too.

Nathan Myers
ncm@cantrip.org  http://www.cantrip.org/


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <316F533D.262C89BD@cantrip.org> Nathan Myers <ncm@cantrip.org>
writes:
> Greg Colvin wrote:
>
> > In article <009A0A5CE1159CC0.49802F14@ittpub.nl> "Wil Evers"
> > <wil@ittpub.nl>:
> > >What I definitely do not understand is why the new auto_ptr template
> > >doesn't even allow us to query if it is actually owning the object
> > >pointed to.
>
> > I found it very hard to contrive examples where is_owner() would
> > actually be useful.
>
> I agree with Greg here: any code that is intended to execute
> differently, depending on the value returned by putative member
> auto_ptr<>::is_owner(), is just bad code.
>
> [snip]
>
> The answer is: it's your responsibility to keep track of ownership
> of pointers; if you can't do it manually, then automate it with
> reference counting or something.  That's not what auto_ptr<> is for;
> its purpose is to make sure that the value "new T" gets destroyed.
> It does that job perfectly; don't ask it to do your job too.

Well, that's all a matter of interpretation.  The previous, simpler,
implementation of auto_ptr used to do that job for me.  I used to rely on
the guarantee that if it was pointing at something, it was pointing at
something alive and unique.  It seemed to me that this was a reasonable
assumption because the DWP stated that auto_ptr implemented the concept of
`strict ownership'.

Imagine, for instance, a collection of ten heap objects in a polymorphic
hierarchy, where each of those is in one of three sets.  Once every now and
then, some of the objects are moved from one of the sets to another.  Why
would it be bad code to implement each of these sets using an array of ten
auto_ptrs?  It seems to me there is nothing inherently good or bad about
such a design, it's just not supported any more.

The fact of the matter is that auto_ptr implements both a guarantee about
the deletion of the pointee when the auto_ptr is destroyed *and* a concept
of transferable object ownership.  The `pointer part' of the auto_ptr
abstraction is well supported in its interface, while the `ownership part'
no longer is.

In one of his previous articles, Greg said that he hated the idea of
exposing the mutable `owner' member through an access function.  Normally,
I would agree, but I think auto_ptr is a special case.  The `owner' flag
has not been made mutable because it represents some implementation detail
that does not effect the logical state of the object; it has been made
mutable because of the problems with returning object ownership from
functions.  One of the rules I use in my class designs is that if a certain
attribute is part of the logical state of an object, users should be able
to query it.

- Wil
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]