On Tuesday, January 28, 2003, at 11:19 PM, Greg Colvin wrote:
My problem with auto_ptr isn't so much the semantics, which have proved useful and are probably the minimum needed to solve the problem that the committee wanted solved. And it isn't so much the "move as copy" syntax that Howard dislikes.
I just read in a newsgroup post today:
I tried to apply predicate version of std::sort algorithm to vector<Now we all know that vector<auto_ptr<MyClass> > won't compile, so this really shouldn't be a problem.
auto_ptr<MyClass> > using my predicate. Sometimes, some of auto_ptr loses
the ownership while sorting. What is happening?
But it still IS a problem, because this does compile:
#include <the proper stuff>
void foo()
{
auto_ptr< MyClass > ia[100];
... fill ia
std::sort(ia, ia+100, the_proper_predicate);
}
This may even do the right thing. Or it may leave an auto_ptr moved into a local inside of sort, never to be heard from again. And the reason is that sort thinks it can copy an element from the range into a local temporary with:
T partition = *median;
If T is auto_ptr, this does a move instead of a copy, with the result that the range to be sorted now no longer contains all of the elements that were supposed to be sorted. The committee recognized this danger in 1996, and redesigned auto_ptr so that it would not compile if put into a std::container. However, you can still put auto_ptr into a raw array, and you can still use std::algorithms on raw arrays. auto_ptr still presents a danger because it moves with copy syntax. A better solution is to move with syntax other than copy so that code like foo() shown above will fail at compile time, instead of at run time (or if it does compile, will run correctly).
-Howard
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
