指针与引用

//---------------------------------------------------------------------
引用是一种没有指针语法的指针.与指针一样,引用提供对对象的间接访问.
－－《c++ primer》p29
虽然引用也可以被用作一种指针，但是象对指针一样用一个对象的地址初始化一个引用却是错误的。
例如：
int i＝0；
int &refi＝i； //ok,refi指向一个i的引用
//int &refi=&i; 错误，不能用指针初始化引用

一旦引用已定义，它就不能再指向其他的对象（这也是为什么必须要被初始化的原因）。
引用所有的操作实际上都被应用在它所指的对象身上，包括取地址操作。例如：
refi＋＝2；
等同于： i＋＝2；

int *j＝&refi；
等同于： int *j＝&i；

－－《c++ primer》p87

//---------------------------------------------------------------------
在下列函数声明中，为什么要同时使用*和&符号？以及什么场合使用这种声明方式?

　　void func1（ MYCLASS *&pBuildingElement ）；

　　论坛中经常有人问到这样的问题。本文试图通过一些实际的指针使用经验来解释这个问题。
仔细看一下这种声明方式，确实有点让人迷惑。在某种意义上，"*"和"&"是意思相对的两个东西，把它们放在一起有什么意义呢？。为了理解指针的这种做法，我们先复习一下C/C++编程中无所不在的指针概念。我们都知道MYCLASS*的意思：指向某个对象的指针，此对象的类型为MYCLASS。 Void func1（MYCLASS *pMyClass）；

// 例如： MYCLASS* p = new MYCLASS；
func1（p）；
上面这段代码的这种处理方法想必谁都用过，创建一个MYCLASS对象，然后将它传入func1函数。现在假设此函数要修改pMyClass： void func1（MYCLASS *pMyClass）
{
DoSomething（pMyClass）；
pMyClass = // 其它对象的指针
}

　　第二条语句在函数过程中只修改了pMyClass的值。并没有修改调用者的变量p的值。如果p指向某个位于地址0x008a00的对象，当func1返回时，它仍然指向这个特定的对象。（除非func1有bug将堆弄乱了，完全有这种可能。）

　　现在假设你想要在func1中修改p的值。这是你的权利。调用者传入一个指针，然后函数给这个指针赋值。以往一般都是传双指针，即指针的指针，例如，CMyClass**。

MYCLASS* p = NULL；
func1（&p）；

void func1（MYCLASS** pMyClass）；
{
*pMyClass = new MYCLASS；
……
}

　　调用func1之后，p指向新的对象。在COM编程中，你到处都会碰到这样的用法--例如在查询对象接口的QueryInterface函数中：

interface ISomeInterface {
HRESULT QueryInterface（IID &iid, void** ppvObj）；
……
}；
LPSOMEINTERFACE p=NULL；
pOb->QueryInterface（IID_SOMEINTERFACE, &p）；

　　此处，p是SOMEINTERFACE类型的指针，所以&p便是指针的指针，在QueryInterface返回的时候，如果调用成功，则变量p包含一个指向新的接口的指针。

　　如果你理解指针的指针，那么你肯定就理解指针引用，因为它们完全是一回事。如果你象下面这样声明函数：

void func1（MYCLASS *&pMyClass）；
{
pMyClass = new MYCLASS；
……
}

　　其实，它和前面所讲得指针的指针例子是一码事，只是语法有所不同。传递的时候不用传p的地址&p，而是直接传p本身：

　　MYCLASS* p = NULL；
　　func1（p）；

　　在调用之后，p指向一个新的对象。一般来讲，引用的原理或多或少就象一个指针，从语法上看它就是一个普通变量。所以只要你碰到*&，就应该想到**。也就是说这个函数修改或可能修改调用者的指针，而调用者象普通变量一样传递这个指针，不使用地址操作符&。

　　至于说什么场合要使用这种方法，我会说，极少。MFC在其集合类中用到了它--例如，CObList，它是一个Cobjects指针列表。

Class CObList : public Cobject {
……

// 获取/修改指定位置的元素
Cobject*& GetAt（POSITION position）；
Cobject* GetAt（POSITION position） const；
}；

　　这里有两个GetAt函数，功能都是获取给定位置的元素。区别何在呢？

　　区别在于一个让你修改列表中的对象，另一个则不行。所以如果你写成下面这样： Cobject* pObj = mylist.GetAt（pos）；

　　则pObj是列表中某个对象的指针，如果接着改变pObj的值： pObj = pSomeOtherObj；

　　这并改变不了在位置pos处的对象地址，而仅仅是改变了变量pObj。但是，如果你写成下面这样： Cobject*& rpObj = mylist.GetAt（pos）；

　　现在，rpObj是引用一个列表中的对象的指针，所以当改变rpObj时，也会改变列表中位置pos处的对象地址--换句话说，替代了这个对象。这就是为什么CObList会有两个GetAt函数的缘故。一个可以修改指针的值，另一个则不能。注意我在此说的是指针，不是对象本身。这两个函数都可以修改对象，但只有*&版本可以替代对象。

　　在C/C++中引用是很重要的，同时也是高效的处理手段。所以要想成为C/C++高手，对引用的概念没有透彻的理解和熟练的应用是不行的。

//---------------------------------------------------------------------
1：int& abc()；函数中&是什么作用？
举个例子：
int x = 0;
int &a(int &i)
{
i = - 1;
return x ;
}
main()
{
int j=10;
a(j)=100;
//这时候j = -1,x = 100.了
}
就是这样子，返回引用的话就是返回一个变量的地址里面的内容，就是真正地返回这个变量本身啦，它可以用作左值，以改变返回的引用的变量的值，j在进入函数后，函数中i和函数外的j是一个变量，返回的值和x是一个变量，所以，经过赋值以后j、x的值变化，在操作符重载=号中这种方式要经常用到，所以掌握这个知识还是很有必要的

2：CList<int,int&>和CList<int int>有什么区别？
"加&主要是为了提高以大型对象为参数时的效率"，对一个大型对象，如果以传值方式传递参数，则整个对象要被复制一份，有可能花很多时间，因此CList让它接受的参数类型也可以定制，这就解决了上面的问题
二者在行为表现上没有任何区别，有区别的仅仅是参数的使用而已
//---------------------------------------------------------------------
指针和引用[转贴]
发信站: 华师陶园站 (Tue Jun 10 14:19:15 2003), 转信

主题:没人发贴？偶发一个问题
偶实在是搞不懂指针和引用有什么不同――
void func(int* p)和void func(int &i)对传进的参数有什么不一样？当然传出时赋值
语句不一样，但是就结果来说是一样的吧？BTW 偶除了C/C++的语法书上外似乎少见人
用过引用传参数。

----------------------------------------------------------------------------

主题:指针更灵活,引用更安全
1.引用比指针更安全,比如:如果调用一个某类型空悬指针(空悬指针:此指针的值不是空,但
是它指向的内容已经被delete了)的成员方法,可能导致系统崩溃;但是引用永远不能是空的
,就不存在这个问题.
2. 指针比引用更灵活
2.1 你可以让一个函数的最后一个参数的类型是指针,缺省值是NULL;在这个函数里面检查
此指针的值,如果是空则做1,如果不是空则做2(会用到这个指针).而如果用引用,则无法实
现.
2.2 对指针可以有++, --这样的操作;而引用永远只能指向一个地方.而且只能在初始化的
时候指定,以后就不能重新指向别的对象了.
----------------------------------------------------------------------------

主题:不能一概而论
安全，小强指的是由于程序员的使用的问题而使指针不安全，难道就说指针不安全吗？我
认为不是这样的，按引用主要用于传递一些结构或者对象之类的大的东西，速度比较快，
按引用并不比指针安全多少，因为在过程里，也有很大可能改变传递的值，指针也是一样
，最主要就是避免野指针的问题，引用我个人觉得比指针好用，呵呵
----------------------------------------------------------------------------

主题:小心小心再小心
C就是比较麻烦就是很多时候CORE DUMP了都不知道在哪里出的错。野指针的问题呢，如果
你在使用完（FREE或DELETE）P之后记住赋个NULL，然后尽量不要再用这个P；做传入参数
的话，函数里第一句话就要判断P是否是NULL再做判断吧；传出参数的话，函数里第二句就
先给它赋个默认值咯。
C里面最怕人家的程序CORE DUMP了，而且要你改，还没有文档，我FT！
----------------------------------------------------------------------------

主题:什么是安全？什么是不安全？
李铁，我不同意你的看法。
什么是安全？什么是不安全？容易让程序员出错的东西就是不安全的，不容易出错的东西
就是相对安全的。即使不用指针，不用引用；也可能出现一个变量是除数，这个变量的值
是零，结果一除，程序倒掉了。你能说“普通自动变量不比指针安全多少”或者“普通自
动变量不比引用安全多少”吗？
编程的不是机器，是人；是人就会犯错误，没有不犯错误的人，除非他不是人。那我们就
要首先认识到容易犯错误的地方，不安全的因素有哪些。再采用一定的体制（或者叫行动
）来减少这些失误，比如代码交叉审核等。
----------------------------------------------------------------------------

主题:回复
人犯错误难道是对的？虽然人会犯错误，但是C不会，它只会按照程序员编写的那样执行，
而不在乎对错，我觉得程序员由于对于指针和引用的东西没有完全掌握的话，实在不能称
为真正合格的程序员，但是由于自身犯的错误，怎么能说是C的问题呢？
其实，如果对指针和引用的底层的东西不熟，只要知道什么时候用指针好，什么时候用引
用好就可以了，不能说因为本身对C的了解的局限，而说什么安全什么不安全，其实有很多
程序员对指针和引用一知半解，并不奇怪，可以找书看看
----------------------------------------------------------------------------

主题:我的一点看法
让我们回到引用和指针参数的区别上来吧。对于杨强的说法，我是大部分同意的，只是第
一点的举例我个人认为不是很恰当，它们的区别应该不在失效指针上，而是说对于指针参
数，函数内部第一件要做的事应该是判空，对非空指针才可以继续操作。此外，它们还有
一个区别，指针参数暴露了函数内部的实现，不够直观，尤其是在重载操作符的时候，举
例来说：
值传递
CTest operator+(CTest param1, CTest param2);
用例：a+b，a+b+c
指针传递
CTest operator+(CTest *param1, CTest *param2);
用例：&a+&b，&(&a+&b)+&c
引用传递
CTest operator+(CTest *param1, CTest *param2);
用例：a+b，a+b+c
指针和引用作为C/C++里面的语法元素，自有它最擅长的地方，只要你用的顺手，也不必拘
泥。
----------------------------------------------------------------------------

主题:第一,对空悬指针判空是没用的.第二,指针参数没有暴露函数内部实现.
第一,对空悬指针判空是没用的.
空悬指针是那些new过之后,又delete了的指针,这个指针的值不是NULL,除非手动赋值成NU
LL.你不能假设所有的程序员在对所有的指针delete之后都给指针赋值成NULL了.应该这么
做的道理我们都懂,但是知易行难,总会有人有疏漏的时候.尽管可能这种疏漏只有很小的几
率.因此通过判断指针是否为空来判断是否是失效指针,这种做法不能完全避免使用无效指
针的可能.
第二,指针参数没有暴露函数内部实现.
过程化编程,以致现在的面向对象编程的核心思想就是隐藏实现细节.函数这种实体本身就
是用来隐藏内部实现的,不管函数用了什么样的参数,除非它返回一个函数内的局部静态变
量的指针(或引用)或者它使用了一个全局变量,你都不能说一个函数暴露了内部实现细节.
而且可以把基类指针作为函数的形式参数,在传实参的时候使用一个派生类的指针;这种做
法恰恰是隐藏函数实现细节,达到系统灵活性和可维护性需求的一个非常常用的方法.
第三,丘兄有句话我不能认同.
指针和引用作为C/C++里面的语法元素，自有它最擅长的地方，只要你用的顺手，也不必拘
泥。
确实有一些地方使用指针和引用都差不多.但是当我们面临选择的时候,使用指针还是引用
绝对不能是靠是否顺手来确定.因为有的时候就是其中一个比另一个好.

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/Augusdi/archive/2009/10/10/4649121.aspx