[boost] auto_ptr/move issue

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2003-01-30 20:24:44

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<
> auto_ptr<MyClass> > using my predicate. Sometimes, some of auto_ptr 
> loses
> the ownership while sorting. What is happening?

Now we all know that vector<auto_ptr<MyClass> > won't compile, so this 
really shouldn't be a problem.

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