I cringe at the thought of bringing up an old subject, but I recently
switched my copy of auto_ptr to a modified "Santa Cruz" auto_ptr, and I
have to say, it's been strange!

The strangeness is, specifically, the lack of a reset() function or an
easy equivalent. Rather than whine about a change that has already been
made, I'd like to know what the mindset of the C++ committee was. Is the
idea that this "assignment after creation" is an unintended use use of
the auto_ptr that should be discouraged? If it's not to be discouraged,
than how are developers expected by the committee to use the new
auto_ptr? The easiest way I can see to assign a new pointer to an
auto_ptr after creation is using code that's something like:

auto_ptr<myclass> ptr(new myclass);
ptr = auto_ptr<myclass>(new myclass);

...whereas the old auto_ptr would be something like:

auto_ptr<myclass> ptr(new myclass);
ptr.reset(new myclass);

I'm not trying to be accusatory or anything; I would like direction as
to the intentions of the committee on this one, if someone wouldn't mind
enlightening me.
---
[ 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
]

In article <m0uM22G-000OjZC@sqarc.sq.com> willer@carolian.com
(Steve Willer) writes:
>I cringe at the thought of bringing up an old subject, but I recently
>switched my copy of auto_ptr to a modified "Santa Cruz" auto_ptr, and I
>have to say, it's been strange!
>
>The strangeness is, specifically, the lack of a reset() function or an
>easy equivalent. Rather than whine about a change that has already been
>made, I'd like to know what the mindset of the C++ committee was. Is the
>idea that this "assignment after creation" is an unintended use use of
>the auto_ptr that should be discouraged? If it's not to be discouraged,

Not exactly discouraged, but not the most important use either.

>than how are developers expected by the committee to use the new
>auto_ptr? The easiest way I can see to assign a new pointer to an
>auto_ptr after creation is using code that's something like:
>
>auto_ptr<myclass> ptr(new myclass);
>ptr = auto_ptr<myclass>(new myclass);

Yep, that's the way.  A decent compiler should of course optimize away the
auto_ptr constructor on the rhs of the assignment.

>...whereas the old auto_ptr would be something like:
>
>auto_ptr<myclass> ptr(new myclass);
>ptr.reset(new myclass);

Shorter by 5 characters and the length of the class name.  A little easier
I suppose.

>I'm not trying to be accusatory or anything; I would like direction as
>to the intentions of the committee on this one, if someone wouldn't mind
>enlightening me.

The real problem was the existing idiom
   p.reset(q.release())
which used to be the same as
   p = q
but would be dangerous with the current semantics.

We wanted to be sure not to create a silent change in this case, and
felt that reset() was of marginal value.  The safest uses of auto_ptr
never traffic in raw pointers anyway, so reset(), release(), and get()
were already compromises.  One less compromise seemed like progress to me.
---
[ 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                             ]