C++自增自减运算符重载int参数的问题

解决为什么自增自减运算符重载带int参数就是后置,不带就是前置的疑问

转自:http://dev.yesky.com/228/2578228.shtm

很久以前(八十年代),没有办法区分++和--操作符的前缀与后缀调用。这个问题遭到程序员的报怨,于是C++语言得到了扩展,允许重载increment 和 decrement操作符的两种形式。

  然而有一个句法上的问题,重载函数间的区别决定于它们的参数类型上的差异,但是不论是increment或decrement的前缀还是后缀都只有一个参数。为了解决这个语言问题,C++规定后缀形式有一个int类型参数,当函数被调用时,编译器传递一个0做为int参数的值给该函数:

class UPInt { // "unlimited precision int"
public:
 UPInt& operator++(); // ++ 前缀
 const UPInt operator++(int); // ++ 后缀
 UPInt& operator--(); // -- 前缀
 const UPInt operator--(int); // -- 后缀
 UPInt& operator+=(int); // += 操作符,UPInts
 // 与ints 相运算
 ...
};

UPInt i;

++i; // 调用 i.operator++();
i++; // 调用 i.operator++(0);
--i; // 调用 i.operator--();
i--; // 调用 i.operator--(0);

  这个规范有一些古怪,不过你会习惯的。而尤其要注意的是这些操作符前缀与后缀形式返回值类型是不同的。前缀形式返回一个引用,后缀形式返回一个const类型。下面我们将讨论++操作符的前缀与后缀形式,这些说明也同样使用与--操作符。

  从你开始做C程序员那天开始,你就记住increment的前缀形式有时叫做“增加然后取回”,后缀形式叫做“取回然后增加”。这两句话非常重要,因为它们是increment前缀与后缀的形式上的规范。

// 前缀形式:增加然后取回值

UPInt& UPInt::operator++()
{
 *this += 1; // 增加
 return *this; // 取回值
}

// postfix form: fetch and increment

const UPInt UPInt::operator++(int)
{
 UPInt oldValue = *this; // 取回值
 ++(*this); // 增加
 return oldValue; // 返回被取回的值
}

  后缀操作符函数没有使用它的参数。它的参数只是用来区分前缀与后缀函数调用。如果你没有在函数里使用参数,许多编译器会显示警告信息,很令人讨厌。为了避免这些警告信息,一种经常使用的方法时省略掉你不想使用的参数名称;如上所示。

  很明显一个后缀increment必须返回一个对象(它返回的是增加前的值),但是为什么是const对象呢?假设不是const对象,下面的代码就是正确的:

UPInt i;
i++++; // 两次increment后缀
// 运算

  这组代码与下面的代码相同:

i.operator++(0).operator++(0);

  很明显,第一个调用的operator++函数返回的对象调用了第二个operator++函数。

  有两个理由导致我们应该厌恶上述这种做法,第一是与内置类型行为不一致。当设计一个类遇到问题时,一个好的准则是使该类的行为与int类型一致。而int类型不允许连续进行两次后缀increment:

int i;
i++++; // 错误!

  第二个原因是使用两次后缀increment所产生的结果与调用者期望的不一致。如上所示,第二次调用operator++改变的值是第一次调用返回对象的值,而不是原始对象的值。因此如果:

i++++;

  是合法的,i将仅仅增加了一次。这与人的直觉相违背,使人迷惑(对于int类型和UPInt都是一样),所以最好禁止这么做。

  C++禁止int类型这么做,同时你也必须禁止你自己写的类有这样的行为。最容易的方法是让后缀increment 返回const对象。当编译器遇到这样的代码:

i++++; // same as i.operator++(0).operator++(0);

  它发现从第一个operator++函数返回的const对象又调用operator++函数,然而这个函数是一个non-const成员函数,所以const对象不能调用这个函数。如果你原来想过让一个函数返回const对象没有任何意义,现在你就知道有时还是有用的,后缀increment和decrement就是例子。(更多的例子参见Effective C++ 条款21)

  如果你很关心效率问题,当你第一次看到后缀increment函数时, 你可能觉得有些问题。这个函数必须建立一个临时对象以做为它的返回值,(参见条款19),上述实现代码建立了一个显示的临时对象(oldValue),这个临时对象必须被构造并在最后被结构。前缀increment函数没有这样的临时对象。由此得出一个令人惊讶的结论,如果仅为了提高代码效率,UPInt的调用者应该尽量使用前缀increment,少用后缀increment,除非确实需要使用后缀increment。让我们明确一下,当处理用户定义的类型时,尽可能地使用前缀increment,因为它的效率较高。

  我们再观察一下后缀与前缀increment 操作符。它们除了返回值不同外,所完成的功能是一样的,即值加一。简而言之,它们被认为功能一样。那么你如何确保后缀increment和前缀increment的行为一致呢?当不同的程序员去维护和升级代码时,有什么能保证它们不会产生差异?除非你遵守上述代码里的原则,这才能得到确保。这个原则是后缀increment和decrement应该根据它们的前缀形式来实现。你仅仅需要维护前缀版本,因为后缀形式自动与前缀形式的行为一致。

  正如你所看到的,掌握前缀和后缀increment和decrement是容易的。一旦了解了他们正确的返回值类型以及后缀操作符应该以前缀操作符为基础来实现的规则,就足够了。

C语言自增自减问题

03-19

baidu提问:rn rn有下列C语言代码: rn#include "stdio.h" rnvoid main () rn rnint i=10; rnprintf("%d,%d,%d\n",++i,--i,-i++); rn rn在VC++中运行结果为10,9,-10 rn但安装教科书上说明:“函数参数的求值顺序是自右向左”,那么计算结果应该是:11,10,-10。请问为什么会得出这个结果?rn rn rn一位高人的回答:rn rnC语言跟大多数语言一样,没有规定表达式的求值顺序,除了以下几个顺序点: rn;(分号,标志一条语句结束) rn,(逗号操作符,函数参数列表里面的逗号只起分隔作用,不是逗号操作符) rn&&和||(逻辑与,逻辑或) rn? : (条件运算符) rn()(if,while,for, do..while,以及函数调用) rn这些统称为顺序点,它们的求值顺序有规定。我这里只给你说明逗号操作符,其他的不一一作介绍(不然能写一大篇呢),你自己参考相关资料。 rn逗号表达式最简单的情形如下: rnexp1, exp2; rnC语言保证exp1在exp2之前求值,并且exp1求值的副作用保证在逗号之前生成。所以象下面这个逗号表达式: rnint i = 1; rni++, (i == 2); rn最后的值就是1,因为逗号表达式的前半部分i++的副作用(i自增1)在逗号之前已经生成,所以当执行到(i == 2)的时候,i的值已经是2了,所以i == 2成立,(i == 2)的值便作为整个逗号表达式的值。 rnrn但是,对函数原型,函数定义,函数调用,C语言里面明确说明,参数列表里面的逗号不是逗号操作符,只起到分隔作用,所以这里的逗号不再是一个顺序点,那它前后的表达式的求值顺序就是任意的,并且所有带副作用的表达式的副作用都要等到下一个顺序点之后才是确定的,也就是说你只有等到下一个顺序点之后,你才能准确得依赖这些表达式产生的副作用。 rn所以,像这样的函数调用 rnfoo(i++, ++i);是得不到准确的结果的。因为这里逗号不是逗号操作符,所以就算编译器选择的是从左到右的求值顺序,由于C语言不再保证i++的副作用在逗号之前生成,算到++i的时候,都不确定i到底有没有自增1,不确定性就在这里产生了。再者,如果编译器选择的是从右到左求值,同样产生不确定性,这样一来,传进函数foo的两个参数的值就可能不同,那么最后的结果当然也就不同了。你这里一样,printf是一个函数, rnprintf("%d,%d,%d\n",++i,--i,-i++); rn是函数调用,括号内的所有逗号都不是逗号操作符,而只起到分隔参数的作用。所以++i,--i,-i++这三个表达式的求值顺序是任意的,编译器想怎么算就怎么算,不同的编译器的“想法”可能相同可能不同,结果就可能一样可能不一样。rnrnrn转http://blog.chinaunix.net/u/17928/showart_259182.html

没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试