Steve Clamage <stephen.clamage_nospam@eng.sun.com> writes:

> The subject of auto_ptr is one of the few unresolved issues before the
> C++ Committee, and it needs to be resolved at the next meeting in
> November. Greg presented the proposal in this thread to the C++
> Committee this week, and it is now being discussed, along with other
> proposals.

[...]

> There are also some minor variations on these themes. Perhaps not
> everyone would agree with my characterizations. I count 140 email
> messages about auto_ptr in the last 10 days. I've read all of them,
> but I won't attempt to summarize the arguments. (Oops, 141. Another
> one arrived while I was writing this.)

Does that include adding a (very obvious) template parameter to
auto_ptr<T> ? Of course, this additionnal parameter has a default
and is Allocator = allocator<T> (so we have
auto_ptr<T, Allocator = allocator<T> >).

I think that this change is orthogonal with what you are talking
about, so that they can be voted independantly and integrated.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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                             ]

stephen.clamage_nospam@eng.sun.com (Steve Clamage) writes:

 |> The subject of auto_ptr is one of the few unresolved issues before the
 |> C++ Committee, and it needs to be resolved at the next meeting in
 |> November. Greg presented the proposal in this thread to the C++
 |> Committee this week, and it is now being discussed, along with other
 |> proposals. I would characterize the other proposals as
 |>  - leave auto_ptr the way it is,
 |>  - make copy semantics undefined,
 |>  - make the copy operations private and thus inaccesible,
 |>  - limit copying to auto_ptrs declared "volatile".

It's hard to be sure, given the amount of discussion going on, but I
think that one of the major proposals was to make the use of a
non-owning auto_ptr illegal in some way (undefined behavior, throw an
exception, ...).

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
        I'm looking for a job -- Je recherche du travail
---
[ 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                             ]

(What's your email Greg ?)

greg wrote:
> In our discussions over the years it remains clear that auto_ptr has
> strange and potentially dangerous copy semantics.  I believe that the
> strangeness is necessary for auto_ptr to do its job,

Yes

> but that the danger
> can be mitigated at a reasonable cost.

I want a compile time solution if possible

> My proposal is simply that most operations on an auto_ptr that does not own
> the object it points to should throw an exception.  In that way dangerous
> uses of auto_ptr will fail quickly and in a well defined way.

I can't accept that cost. get() is trivial and will be inlined, so now
it costs only a MOVE or even nothing; your get() wil cost a TST and a
never
taken JMP, which IMO isn't acceptable.

Perhaps your machine supports invalid pointers, but the ones I am
working on
(68000 and PowerPC) don't.

> Does this proposal hurt performance?  It might.  If a hardware trap is
> unavailable an extra test, branch, and throw is required in the get()
> member function.  However, with this change it is no longer necessary to
> maintain a separate ownership bit, so the size of the auto_ptr can be
> smaller and the speed of constructing, copying, and destroying an auto_ptr
> can be faster.

If you want to avoid the ownership bit, go back to the previous auto_ptr
where non-owning have a value 0.

> Will this proposal break existing code?

That's ok.

> Will this proposal make auto_ptr work with the standard containers?  No,
> but it will replace undefined behavior with a throw.

Only ref-counted ptr can work with the std containners.

Summary of the goals:

- make get() efficient
- efficiency of ctor is less important (often a ctor call follows an
  operator new call which is itself inneficient)
- make stupid programs ill-formed (like vector<auto_ptr>)
- make it easy to understand
- make it a normal class: that's impossible

What about making the copy non-const ?

auto_ptr (auto_ptr& rhs) : p (rhs.p) { rhs.p = 0; }
void operator= (auto_ptr& rhs) { p = rhs.p; rhs.p = 0; }
auto_ptr& me () { return *this; }

With the following usage:

auto_ptr<int> foo ()
{
    auto_ptr<int> p (new int(4));

    return p;
}

auto_ptr<int> p = foo ().me ();

Thus you can't put auto_ptr in a containner without some
kind of diagnostic about non-const reference binded to
const objects.

I explain annother solution on my web pages at (in french):

http://www.pratique.fr/~bonnardv/guide_cpp.html#class.alloc.copy

The idea is to have two classes: auto_ptr and ret_auto_ptr;
you normally use auto_ptr; if you want to return an auto_ptr
the function must have a return type ret_auto_ptr.

You can't copy auto_ptr to auto_ptr, but you can copy
auto_ptr to ret_auto_ptr and ret_auto_ptr to auto_ptr.

There is no ownership bit, but the pointer value has to
be mutable.

It's pretty difficult to get a non-owning auto_ptr. You
can't put it in a containner.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ 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                             ]

On 09 Oct 97 09:08:43 GMT, Greg Colvin wrote:

>In our discussions over the years it remains clear that auto_ptr has
>strange and potentially dangerous copy semantics.  ...
>
>My proposal is simply that most operations on an auto_ptr that does not own
>the object it points to should throw an exception. ...

A few things should be mentioned regarding Greg's article, so I will
do so. :-)

Greg is a respected, long-time member of the C++ Committee, and
submitted the original auto_ptr proposal. The version that was
ultimately adopted differed from his proposal in having copy
semantics.

The subject of auto_ptr is one of the few unresolved issues before the
C++ Committee, and it needs to be resolved at the next meeting in
November. Greg presented the proposal in this thread to the C++
Committee this week, and it is now being discussed, along with other
proposals. I would characterize the other proposals as
 - leave auto_ptr the way it is,
 - make copy semantics undefined,
 - make the copy operations private and thus inaccesible,
 - limit copying to auto_ptrs declared "volatile".
There are also some minor variations on these themes. Perhaps not
everyone would agree with my characterizations. I count 140 email
messages about auto_ptr in the last 10 days. I've read all of them,
but I won't attempt to summarize the arguments. (Oops, 141. Another
one arrived while I was writing this.)

---
Steve Clamage, stephen.clamage_nospam@eng.sun.com
( Note: remove "_nospam" when replying )
---
[ 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                             ]