std::unique_ptr可以同时处理普通指针和指向数组的指针：

unique_ptr像是auto_ptr的功能改良版

第一个改进就是可以管理指向单一对象的指针，也可以管理指向连续对象（数组）的指针。

第二个，unique_ptr改进的是，auto_ptr最大的黑暗面：“偷偷摸摸”的，看似“复制”其实却是“转移”的操作。

std::unique_ptr<S> s1(new S);
std::unique_ptr<S> s2(s1); //Error, 拷贝构造，不行
std::unique_ptr<S> s3 = s1; //Error, 直接赋值，也不行

s2想以s1为模复制，失败；s3使用赋值操作（但通常会被优化成拷贝构造）也失败。

unique_ptr对象将裸指针看得相对紧一点，不容易发生突然就转交给别的对象的事情。

如果在使用过程中确实需要转移，方法一是让源对象清晰明确地主动释放：

std::unique_ptr<S> s1(new S);
//主动声明'放手'后，可以转移至别人
std::unique_ptr<S> s4(s1.release());

s1主动调用release()方法，返回放手后的裸指针，然后作为另一个unique_ptr对象的构造入参，实现所有权转移。

另一个方法是使用转移语义，调用标准库的move()方法：

std::unique_ptr<S> s1(new S);
//支持标准库转移函数
std::unique_ptr<S> s4 = std::move(s1); 

从字面上看，无论是自愿的“release()(释放)”还是被外部强行“move()”(转移)，语义都非常明确，不容易误解误用。

一旦主动释放或被转移，原unique_ptr对象所拥有的裸指针就是空指针nullptr。原裸指针的管理责任，由接手者负责，这些功能和auto_ptr并无两样。

unique_ptr砍掉了一些功能（禁止拷贝构造和赋值复制），然后正好有函数release(),

unique_ptr明确（采用“= delete”的方法）禁用了拷贝构造和复制操作，从而杜绝了auto_ptr面子上在“复制”，私下里却在“转移”的危险行为；但是如果碰上看起来是在复制但其实是在转移的安全行为，unique_ptr却又能放宽政策。

unique_ptr是在对“转移”语义有良好定义的C++11新标的背景下引入的智能指针，所以它也能“识别”出哪些转移行为是安全可执行的，哪些是危险不能偷着来的。

先看危险的：

std::unique_ptr up1(new int);
std::unique_ptr up2 = up1;//不允许

为什么不能通过第二行代码，将up1所管理的裸指针，转移给up2？因为up1此时也还活着，就这样借着第二行代码（这可是一句复制操作）转移出去，也许up1是自愿的，可这也许这根本就是某些程序员技艺不精或一时糊涂写错的啊（程序员本意也许就是想复制）。万一是后者，会让up1有冤无处说，最终搞垮整个程序。

这种情况下，unique_ptr要求程序员明确指出，我是要转移：

std::unique_ptr up2 = std::move(up1); //OK!

一切都要“明确！明确！”

再来看另一个危险情况：

void UsePtr(std::unique_ptr<int> aup)
{
    assert(aup);
    cout << *aup << endl;
}

注意，函数入参aup不是引用，也不是指针(原始指针)，所以想调用该函数，必须复制一个unique_ptr <int> 的对象传进去，但这是被禁止的：

void test()
{
    std::unique_ptr <int> upi(new int(0));
    UsePtr(upi); //编译失败
}

编译失败，因为upi无法以传值(复制)的方式，传给UsePtr。根据需要，有两种解决方法，一是修改UsePtr，将其入参改为引用或指针，以前者为例：

void UsePtr2(std::unique_ptr<int>& aup)

这是常见的需求，即指针还是那个指针。如果确实需要将调用处的智能指针转移给函数入参，那就回到使用move的方法：

void test()
{
    std::unique_ptr <int> upi(new int(0));
    //转移之后，upi对象所拥有的裸指针就变为空
    UsePtr(std::move(upi)); //编译通过！
}

此时调用处的代码明确写着“move”，这也是对调用者最好的提醒：你定义的upi所管理的内存，已经被转移走了，因此upi内部裸指针已经是nullptr了，请不要再访问它了。这个例子也演示了如何使用std::unique_ptr作为函数入参。

安全的情况：

如果一个对象（通常是匿名对象）马上就要“死了”，那么就可以大大方方地把这个对象所占用的内存转移过来，典型的如一个函数返回的临时对象：

std::unique_ptr <int> CreatePtr(int value)
{
    std::unique_ptr <int> result(new int(value));
    return result;
}

void test2()
{
    //看似复制，其实转移
    std::unique_ptr <int> r = CreatePtr(1000000); 
}

函数的返回值，被放在函数调用栈找那个，如果它不是指针，也不是引用，那就意味着它很快就会消亡，因此它就是一个临时对象。test2()中，变量r就从容地“转移”走了CreatePtr()返回的unique_ptr所拥有的裸指针。如果你不放心编译器，或者有道德洁癖，可以坚持这样写：

std::unique_ptr <int> r2 = std::move(CreatePtr(1000000));

这个例子也用于演示如何使用std::unique_ptr作为函数返回值。

unique_ptr语义明确，并且也方便在函数建传递，因此它进入了标准库。

我们建议，如果只需要一个有长生命周期的堆对象，并不需要多个指针同时指向该对象时，就可以使用unique_ptr管理。

再次体现：unique_ptr也可以用来管理一堆“堆对象”（数组）。

当unique_ptr在管理一个堆数组时，有没有办法从它身上得知所管理的数组包含了几个元素？

原始的堆数组，它其实就是一个指针，除了靠自行记忆，当我们手上有一个指针，除非搞“黑科技”，否则我们还真不能识别出它是指向一个对象，还是指向一组对象，如果是后者，更无法得知所指向的数组有多大。

让unique_ptr负责管理一个堆数组时，它同样没法给出数组大小的信息。

【小提示】：如何临时从智能指针对象上取得裸指针

boost::scoped_ptr和std::unique_ptr都提供get()成员以返回其管理的裸指针（只是返回，并没有像release()那样交出管理权）。

由于unique_ptr同时也能管理堆数组，此时get()返回的指针，就是指向该数组（一块连续内存）的指针。

除了要和纯C的接口对接，否则我们很少有调用get()以取得裸指针的需要。