所谓的smart pointers，是“看起来、用起来、感觉起来像内置指针，但提供更多的机能”的一种对象。
smart pointers拥有以下各种指针行为的控制权：
-
构造和析构（Construction and Destruction）
-
复制和赋值（copying and Assignment）
-
解引（Dereferencing）
Smart pointers由templates产生出来。由于它们像内置指针一样。所以必须有“强烈的类型性”（strong typed），用户可利用templateca那是表明其所指对象的类型。大部分看起来如下：
template<class T>
class SmartPtr
{
public:
SmartPtr(T* realPtr = 0);
SmartPtr(const SmartPtr& rhs);
~SmartPtr();
SmartPtr& operator = (const SmartPtr& rhs);
T* operator->() const;
T& operator*() const;
private:
T* pointee;
};这里的copy constructor和assignment operator都是public，如果你的smart pointer不允许复制或赋值可以声明为private，两个解引用操作符被声明为const，因为解引所指之物并不改变指针本身。此外，每个smart-pointer-to-T都内含一个dumb pointer-to-T，后者才是真正的主角。
进入smart pointer的实现细节之前，应该先看看clients如何使用smart pointers，考虑一个分布式系统，其中某些对象位于本地，有些位于远程，本地对象的访问通常比远程对象的访问简单且快速，因为远程对象访问可能需要remote procedure calls（RPC）或其他某种与不同机器的沟通的方法。
对于应用程序而言，如果本地对象和远程对象的处理方式不同，是件麻烦的事情。让所有对象都好像位于本地，应该是比较简单的做法。程序库可以提供smart pointers，实现此幻象：
template<class T>
class DBPtr
{
public:
DBPtr(T* realPtr = 0);
DBPtr(DataBaseId id);
...
};
class Tuple
{
public:
...
void displayEditDialog(); //呈现一个图形对话框，允许用户输入tuple
bool isValid() const;
};
template<class T>
class LogEntry
{
public:
LogEntry(const T& objectToBeModified);
~LogEntry();
};
void editTuple(DBPtr<Tuple>& pt)
{
LogEntry<Tuple> entry(*pt);
do
{
pt->displayEditDialog();
}while(pt->isValid == flase);
}
editTuple所编辑的数据可能位于远程，但是editTuple撰写者并不需要操心这样的事情：智能指针类会对系统隐瞒此事，程序员关心的，所有数据（上述的tuple）除了声明形式之外，都应该像内置指针一样被使用。
- Smart Pointers的构造、赋值、析构
考虑C++的标准程序库提供的auto_ptr template。auto_ptr对象是个smart pointer，用来指向诞生于heap内的对象，知道该auto_ptr被销毁为止。当销毁发生时，auto_ptr的destructor会删除其所指物。
auto_ptr template可能实现如下：
template<class T>
class auto_ptr
{
public:
auto_ptr(T* ptr):pointee(ptr){}
~auto_ptr(){delete pointee;}
...
private:
T* pointee;
};在“同一对象只可被一个auto_ptr拥有”的前提下，上述做法可以有效运作。但一旦auto_ptr被复制或被赋值，会发生什么？
auto_ptr<TreeNode> ptn1(new TreeNode);
auto_ptr<TreeNode> ptn2 = ptn1;
auto_ptr<TreeNode> ptn3;
ptn3 = ptn2; 如果我们只是复制其内的dump pointer（浅拷贝），会导致两个auto_ptrs指向同一个对象，这会造成麻烦，因为每一个auto_ptr都会在被销毁时，删除其所指之物，这表示对象会被删除两次，其结果未定义。
另一种做法是以new操作符为其所指对象产生一个新副本，这保证我们不会有多个auto_ptr指向同一个对象（深拷贝），但是这可能会是新对象的但是（以及后来的析构）形成无法让人接受的性能冲击。此外，我们不一定能够确知产生什么样类型的对象，以为一个auto_ptr<T>不一定指向一个类型为T的对象，可能指向一个T的派生类对象。Virtual constructors可以协助解决这个问题，但是在一个像auto_ptr这么目标广泛地class内使用新技术，不合适。
如果我们禁止auto_ptr被复制和赋值，问题就解决了。但是auto_ptr采用一个更富弹性的解法：当auto_ptr被复制和赋值，其“对象”拥有权“会转移：
template<class T>
class auto_ptr
{
public:
auto_ptr(auto_ptr<T>& rhs);
auto_ptr<T>& operator = (auto_ptr<T>& rhs);
...
};
template<class>
auto_ptr<T>::auto_ptr(auto_ptr<T>& rhs)
{
pointee = rhs.pointee; //将*pointee的拥有权转移至*this
rhs.pointee = 0; //rhs不再拥有任何东西
}
template<class>
auto_ptr<T>& auto_ptr<T>::operator = (auto_ptr<T>& rhs)
{
if(this = &rhs)
return *this;
delete pointee;
pointee = rhs.pointee;
rhs.pointee = 0;
return *this;
}注意：assignment操作符在掌握一个新对象的拥有权之前，必须删除它所拥有的对象。如果没有这么做，该对象绝不会被删除。记住，只有auto_ptr对象才“拥有”它所指之对象。
由于auto_ptr的copy constructor被调用时，对象拥有权转移了，所以以by value方式传递auto_ptrs往往是个非常糟糕的注意（因此STL容易绝对不适合放置auto_ptrs）。下面是原因：
void printTreeNode(ostream& os,auto_ptr<TreeNode> p)
{
os << *p;
}
int main()
{
auto<TreeNode> ptn(new TreeNode);
...
printTreeNode(cout,ptn); //以by value方式传递auto_ptr
}当printTreeNode的参与p被初始化，ptn所指对象的拥有权被转移至p。当printTreeNode结束，destructor会删除它指之物，所以printTreeNode被调用后，任何人使用ptn已经会导致未定义的行为。
所以一般使用auto_ptr，pass-by-refrence-to-const才是适当的途径。
- 实现Dereferencing Operators（解引操作符）
现在把注意力放在smart pointers的核心：operator*和operator->函数身上，前者返回所指对象：
template<class T>
T& SmartPtr<T>::operator*() const
{
perform "smart pointer" processing;
return *pointee;
}上述返回的是reference形式。这涉及到两个原因：1、pointee可能指向的派生类对象，如果返回对象，就会导致切割问题。2、reference效率更加高。
operator->和operator*差不多，但是检验operator->之前，会议此函数的一个不寻常的意义，再次考虑editTuple，其中用到一个smart pointer-to-tuple：
void editTuple(DBPtr<Tuple>& pt)
{
LogEntry<Tuple> entry(*pt);
do
{
pt->displayEditDialog();
}while(pt->isValid == false)
}其中的语句pt->displayEditDialog()会被编译器解释为(pt.operator->())->displayEditDialog();这意味着不论operator->返回什么，在该回传值身上施行->操作符都必须是合法的。因此operator->只可能返回两种东西：一个dumb pointer，或者一个smart pointer，大部分你会想要返回一个普通的dump pointer，于是你这样实现operator->：
template<class T>
T* SmartPtr<T>::operator->() const
{
perform "smart pointer" processing;
return pointee;
}- 测试Smart Pointers是否为NULL
上面讨论的函数，可以产生、销毁、复制、赋值、解引用smart pointers。但是有一件事我们没办法做，那就是判断它是否为null：
SmartPtr<TreeNode> ptn;
...
if(ptn == 0) ... //错误
if(ptn) ... //错误
if(!ptn) ... //错误为我们smart pointer classes加上一个isNull函数很容易。但是不能解决“smart pointers 无法入dumb pointers那般自然的测试是否为null”这个枷锁。另一种做法是，提供一个类型转换操作符，允许上述动作得以通过编译，这类转换的传统目标是void*：
template<class T>
class SmartPtr
{
public:
...
operator void*(); //如果dumb ptr是null，返回零
//否则返回非零值
};
SmartPtr<TreeNode> ptn;
...
if(ptn == 0) ... //可以
if(ptn) ... //可以
if(!ptn) ... //可以这类似iostream classes提供的一种转换功能，同时解释了为什么可以这么写代码：
ifstream inputFile("datafile.data");
if(inputFile) //测试inputFile是否成功开启但是这类型转换有一个缺点，就是允许你把不同的smart pointers拿来做比较：
SmartPtr<Apple> pa;
SmartPtr<Orange> po;
...
if(pa == po) //竟然可以过关我们没有为SmartPtr撰写operator ==函数，但是由于两个smart pointers都可以被隐式转换为void*指针，针对语言内置指针，存在比较函数，所以可以通过编译。这种行为使得隐式转换函数非常危险。
有种差强人意的做法，允许你提供“测试nullness”的合理语法。而且能够将“以外引起不同类型的smart pointers相互比较“的机会降到最低，那就是重载”！操作符“，并在其调用者（某smart pointer）是null的情况下，返回true：
template<class T>
class SmartPtr
{
public:
...
bool operator!() const; //只有当smart ptr是null才返回true
...
};这使得clients可以这么写：
SmartPtr<TreeNode> ptn;
...
if(!ptn)
{
...
}else{
...
}但是你不能这么写：
if(ptn == 0) ... //错误
if(ptn) ... //错误唯一的风险是这样：
SmartPtr<Apple> pa;
SmartPtr<Orange> po;
...
if(!pa == !po) //这样写通过了。。C++标准库中，“隐式转换为void*”已被“隐式转换为bool”取代，而operator bool总是返回operator！的相反值。
- 将Smart Pointers转换为Dumb Pointers
例如你有些老旧函数并非smart pointers：
class Tuple{...};
void normalize(Tuple* pt); //用的是dumb pointer如果你调用normalize并非指定一个smart pointer-to-Tuple给它，将是错误的：
DBPtr<Tuple> pt;
...
normalize(pt); //错误
因为目前没有办法可以将DBPtr<Tuple>转换成一个Tuple*。如果这样可以：
normalize(&*pt); //难看，但是合法如果为smart pointer-to-T template加上一个隐式类型转换函数，便可转换为dumb pointer-to-T，先前的调用便可以成功：
Template<class T>
class DBPtr
{
public:
...
operator T*() const; //新增的转换操作符
...
};
DBPtr<Tuple> pt;
...
normalize(pt); //现在成功了上述函数一旦加入，nullness测试问题也一并解决了：
if(ptn == 0) ... //可以
if(ptn) ... //可以
if(!ptn) ... //可以如果这样设计，clients得意轻易地直接对dumb pointers操作，那就与设计smart pointer目的相违背：
void procesTuple(DBPtr<Tuple>& pt)
{
Tuple* rawTuplePtr = pt; //将DBPtr<Tuple>转换为Tuple*
use rawTuplePtr to modify the tuple;
}通常，smart pointer所提供的灵巧行为应该是你的一个基础设计思维，所以“允许clients直接使用dumb pointers”往往导致灾难。例如，如果DBPtr实现出引用计数，那么“允许clients直接使用dumb pointers”机会肯定会导致簿记的错误，造成引用计数用的结构体崩溃。
你可以提供一个隐式转换操作符，可以将smart pointer转换其内部的dumb pointer，你的smart pointer还是无法完全取代dumb pointer，因为“从smart pointer 转换为dumb pointer”是用户定制的行为，而编译器禁止一次施行一个以上这类转换,例如：
class TupleAccessors
{
public:
TupleAccessors(const Tuple* pt);
...
};
上述可发生隐式类型转换，将Tuple*转换为TupleAccessors，如下函数将两个TupleAccessors对象的内容合并在一起：
TupleAccessors merge(const TupleAccessors* tal,const TupleAccessors* ta2);
由于Tuple*可以被隐式转换成TupleAccessors，所以两个dumb pointers Tuple*作为自变量调用merge没问题，然而以两个smart pointers DBPtr<Tuple>调用，就会失败。
那是因为从DBPtr<Tuple>转换成TupleAccessors需要两个用户自定义转换（第一个从DBPtr<Tuple>转换成Tuple*,第二个将Tuple*转换成TupleAccessors），这是C++禁止的。
Smart pointers classes如果提供隐式转换为dumb pointer，便打开了潘多拉的盒子：
DBPtr<Tuple> pt = new Tuple;
...
delete pt;
所以，不要提供对dumb pointer的隐式转换操作符，除非不得已。
- Smart Pointers和“和继承有关的”类型转换
假设我们有一个public inheritance继承体系，构建出消费性音乐产品:
class MusicProduct
{
public:
MusicProduct(const string& title);
virtual void play() const = 0;
virtual void displayTile() const = 0;
...
};
class Cassette: public MusicProduct
{
public:
Cassette(const string& title);
virtual void play() const;
virtual void displayTile() const;
...
};
class CD: public MusicProduct
{
public:
CD(const string& title);
virtual void play() const;
virtual void displayTile() const;
...
};更进一步假设有个函数，个它一个MusicProduct对象，它就显示标题并播放：
void displayAndPlay(const MusicProduct* pmp,int numTimes)
{
for(int i = 0; i <= numTimes; ++i)
{
pmp->displayTile();
pmp->play();
}
}
我们可以这样使用函数：
Cassette* funMusic = new Cassette("Alapalooza");
CD* nightMareMusic = new CD("Disco Hits of the 70s");
displayAndPlay(funMusic);
displayAndPlay(nightMareMusic);但是如果我们将dumb pointers以其smart pointers替换，就会错误。
void displayAndPlay(const SmartPtr<MusicProduct>& pmp,int numTimes);
SmartPtr<Cassette> funMusic(new Cassette("Alapalooza"));
SmartPtr<CD> nightMareMusic(new CD("Disco Hits of the 70s"));
displayAndPlay(funMusic); //错误
displayAndPlay(nightMareMusic); //错误
之所以无法通过编译，是因为没办法将Smart<CD>或Smart<Cassette>转换为SmartPtr<MusicProduct>。对于编译器来说，是3个各不相干的class。因为这些类没有继承关系，
我们可以用个方法来解决：令每一个smart pointer class有一个隐式转换的操作符，用来转换至smart pointer class。例如，在上述音乐产品中，我们可以将Cassette和CD的smart pointer classes加上一个SmartPtr<MusicProduct>操作符：
class SmartPtr<Cassette>
{
public:
operator SmartPtr<MusicProduct>() //新增的类型转换符
{
return SmartPtr<MusicProduct>(pointee);
}
private:
Cassette* pointee;
};
class SmartPtr<CD>
{
public:
operator SmartPtr<MusicProduct>() //新增的类型转换符
{
return SmartPtr<MusicProduct>(pointee);
}
private:
CD* pointee;
};此做法有两个缺点：第一，你必须一一为每一个“SmartPtr class实例”加上上述式子，由于编译器禁止一次执行一个以上的”用户定制的类型转换函数“，所以无法将一个smart pointer-to-T转换为一个smart pointer-to-indirect-base-class-of-T。
有一个办法可以让编译器完成这些隐式类型转换，这个就是nonvirtual member function声明为template，你可以这样来产生smart pointer的转换函数：
template<class T>
class SmartPtr
{
public:
SmartPtr(T* realPtr);
T* operator->() const;
T& operator*() const;
template<class newType> //template function用于
operator SmartPtr<newType>() //隐式类型操作符
{
return SmartPtr<newType>(pointee);
}
};我们回到CDs,Cassettes和和MusicProduct继承体系，稍早我们看到代码无法通过编译，因为没有任何途径可以让编译器将“指向CDs或Cassettes”的smart pointers转换为“指向MusicProduct”的smart pointers，现在使用修改版本的smart pointer class，令其member function template作为隐式类型转换符，上述便成功。将SmartPtr<Cassette>转换成SmartPtr<MusicProduct>，编译器产生这样的代码：
SmartPtr<Cassette>::operator SmartPtr<MusicProduct>
{
return SmartPtr<MusicProduct>(pointee);
}这里调用了SmartPtr<MusicProduct> constructor，并以pointee作为自变量。SmartPtr<MusicProduct> constructor期望一个MusicProduct*指针，但现在我们面对的是dumb pointer类型间的转换，所以很明显Cassette*可以被交给一个期望获得MusicProduct*的函数。
此法不仅只适合于集成体系的向上转换，对于指针类型之间的任何合法的隐式转换都能成功。如果你手上有个dumb pointer类型的T1*，另一个dumb pointer类型的T2*，只要你能够将T1*隐式转换为T2*，你便能够将smart pointer-to-T1隐式转换为smart pointer-to-T2。
假设我们扩充MusicProduct继承体系，加上一个新的CaSingle class，修改集成体系如下：
template<class T>
class SmartPtr{...}; //如上，其中包含指针对转换操作符而设计的
//的member function template
void displayAndPlay(const SmartPtr<MusicProduct> pmp,int howMany);
void displayAndPlay(const SmartPtr<Cassette> pmp,int howMany);
SmartPtr<CasSingle> dumbMusic(new CasSingle("AchyBreakyHeart"));
displayAndPlay(dumbMusic,1); //错误上述错误的原因，displayAndPlay调用动作是一种模棱两可的行为，因为从SmartPtr<CasSingle>转换到Smart<Cassette>并不比转换至SmartPtr<MusicProduct>更好。
利用member templates来转换smart pointer有两个缺点：第一，目前支持member templates的编译器不多（现在应该并不存在这个问题了）；第二，期间涵盖的技术并不简单，你不洗熟悉（1）函数调用的自变量匹配规则、（2）隐式类型转换函数、（3）template functions的暗自实例化、（4）member function templates技术。
我们真正想要的将“smart pointers classes”的行为在“与继承相关类型转换”能够和dumb pointers一样。答案很简单：不能够，smart pointers虽然smart，却不是pointer，我们所能做的最好情况就是使用member templates来产生转换函数，然后在其中出现模棱两可的时候使用转型动作。这并不完美，但是够好。
- Smart Pointers 与 const
dumb pointers可以指定本身或者所指之物为const，但是smart pointers只能有一个地方放置const：只能施行于指针本身，不能用于所指的对象。
CD goodCD("Flood");
const CD* p; //所指之物为const
CD* const p = &goodCD; //指针为const
const CD* const p = &goodCD; //两者都是const
const SmartPtr<CD> p = &goodCD; //指针本身为const矫正的我们可以方法，用smart pointer指向一个cons CD来：
SmartPtr<const CD> p = &goodCD; //所指之物为const但是这里的办法有缺陷，如果使用dumb pointers，我们可以将non-const指针作为const指针的初值：
CD* pCD = new CD("Famous Movie Themes");
const CD* pConstCD = pCD; //可以但是放在smart pointers做相同的动作却不行。因为SmartPtr<CD>和SmartPtr<const CD>是完全不同的类型，如果你的编译器支持member templates你可以先前的所示技术，自动产生你所需要的隐式类型转换操作符。
类型转换如果涉及const，便是一条单行道：从non-const 转换成const是安全的，反之却不行。此外能够对const做的事情，也都可以对non-const指针进行。这些规则和public inheritance的规则很类似。实现smart pointers时我们可以利用这种性质，令一个smart pointer-to-T class公开继承自smart pointer-to-const-T class:
template<class T>
class SmartPtrToConst
{
public:
... //一般都会有smart pointer member
functions;
protected:
union{
const T* constPointee; //给SmartPtrToConst使用
T* pointee; //给SmartPtr使用
};
};
template<class T>
class SmartPtr:public SmartPtrToConst<T>
{
... //没有data members
}运用这样的设计，我们可以获得希望的行为：
SmartPtr<CD> pCD = new CD("Famous Movie Themes");
SmartPtrToConst<CD> pConstCD = pCD; //没问题