二、挑战#define
#define是C提供的一条很有用的指令,但在C++中,很有可能杜绝宏指令的使用。
1 .const
宏指令允许用户指定某一标识符的值作为一个常量,如:
#define PI 3. 1415926
它也可以用来定义字符串:
#define HZK16 "HZK16F"
以下使用可以通过:
cout << "PI is“<<PI;
cout << "Filename: "<< HZK16;
但宏毕竟不是一个合法的对象,虽然它伪装得很完美。C++为用户提供了常量修饰符const,可以指定某个对象的值为常量。它阻止用户对其进行赋值或其它副作用,类似于上例:
但对于指针的处理似乎有些复杂,例如以下使用却又合法:
HZK16[5]=’r’; //ok HZK16 ="HZK16K"
清楚地了解const修饰的范围很有必要,如下是声明形式与相应含义:
因此,以下使用仍合法:
strcpy(cpl "Oh no...“);
cp2++;
因为cpl只管盯住某一处的地址不放,而阻止其中的内容不被改写则不是它的责任,cp2则恰恰相反,它不允许你修改其中的内容,却可以被你指来指去(这个下场可能更惨)。只有使用两个修饰符(如cp3)才可能是最保险的办法。
指向const的指针不能被赋给指向非const的指针:
float*p=&PI;
//error: Cannot convert 'const float*’ to 'float*’
*p=3.14;
这条限制保证了常量的正当含义。但注意由显式转换所引起的常量间接修改是可能的:
Yahoo!
**作者按:以上程序在Visual C++下运行会报内存错误。
2.内联函数(in line function)
宏在某些场合能得到类似于函数的功能,如下是一个常见的例子:
#define ADD (a b) ((a)+(b))
cout<<”1+2=”<<ADD(1 2);
它将实现数据求和功能而输出:
但我们至少有一打理由拒绝使用它,以下是最明显的:
①宏缺少类型安全检测,如:
ADD ('A' 0. 0l);
这样的调用将被解释为合法,而事实上,很少的用户期望能写出这样的语句;
②宏不会为参数引入临时拷贝,如:
#define DOUBLE (x)((x)+(x))
int i(1);
cout<<DOUBLE(i++); //prints '3'
③宏不具有地址,例如可能在一个计算器程序中有:
case ' +': Operator = & ADD;
并不能得到合理解释。
采取函数?然而,使用函数并不是最划算的支出,它浪费了宝贵的执行时间。使用过汇编语言的读者可能知道,一般函数执行真正的函数体前后,要做一些现场保护工作,当函数体积很小时,这种冗余的工作量将会远远大于函数本身。
为此,C++提供了关键字inline,当用户希望编译器将某函数的代码直接插入到调用点时,可将其设置成inline函数,即在函数定义时加上关键字inline,如:
主函数将被编译器解释为:
count<<"1+2=”<<{1+2 };
其行为完全类似于前例的ADD (a b)宏。
经验表明,将使用频繁而且体积很小的函数声明为inline是明智的。
3.函数重载(overload)
在实际数据求和操作时,如上节内容中提供的Add()函数是远远不够的,你不得不再添加一些其它代码,如:
特别地,在C++中你可以玩弄名字的技巧,将以上的AddDouble AddFloat皆取名为Add,如:
尽管放心,编译器会安全地为不同的调用形式找到相应的函数原型。如:
这样,不同的函数拥有相同的函数名,即函数重载。函数重载以及后面的模板、虚函数机制形成了“一个接口,多种功能”的特性,即多态性(polymorphism),它是面向对象(OO)的技术之一。
在使用重载机制时,C++提出了许多防止二义性的限制,如:
很可能引起C ++编译器的恐慌,它在遇到诸如fun(100)的调用时会十分不满。用户有义务保证任一调用形式不产生二义性。以下是一种常见的使用重载机制的例程:
可以想象C++将以上不同的Pixel()函数分别编码为Pixel_iii和Pixel_ii,它的形式包含了各入口参数的数据类型。注意,编码未包含返回值的信息,因而依赖于返回值类型的差异的函数重载是不稳定的。因此,连接器(linker)可以毫不费力地找到相应的模块。但这对于新旧C版本产生的模块连接恐怕添加了麻烦,因为传统的C函数库中并没有对函数名再作手脚的坏习惯,C++不得不提供关键字extern来保证这种连接的安全性,如下形式(注意’C’可要大写):
将告诉编译器只需要在函数库中找相应的Pixel模块,而不必自作聪明。而
则声明包含在头文件function. h中所有函数模块皆采取C连接。
4.函数模数(function template)
前面讨论的重载机制用来实现求和操作并不受欢迎,这仿佛还不是C++的风格,例如用户需要求两个其它类型(如字符型)对象的和:
Add ('a' ’b’);
它必须再为之准备一个版本,尽管其名字和代码还是那副样子:
这样无聊的工作会让灰心的用户开始怀念起古老的“宏”。然而,更先进的东西一一模板,却可以很方便地解决以上问题:
<class TYPE>作为模板参数表示了数据类型。在实际的调用中,编译程序根据实际使用的数据类型产生相应的函数。如:
将得到编译器正确的解释。但以下的使用:
理所当然地会遭到编译器的拒绝。
以上建立起来的Add)函数模板可以覆盖前面所有的Add()函数,但再来看看以下语句:
同理,编译器根据Add ()模板定制成:
c=(c1 +c2 };
这样的结果是没有定义的,计算机很容易对两个复数的加法不知所措而大发牢骚:
Error: Illegal structure operation
既然计算机不喜欢这个作品,没关系,我们为它再做一个函数就是了:
这个函数用以正确地作复数求和。奇怪得很,函数名居然还可以取为Add,而不用担心任何冲突。对这种情形也有很好的说法,C++称之为“函数模板重置”。
在调用形式上,函数模板很类似于宏,但它同时具有类型检查。更普遍的,模板也可以应用于类中。
至此,对抗#define之战已快接近尾声,然而这似乎永远不得结束。宏就是宏,它总有它的优点,譬如它可节省对象空间,你无法阻止有些C++用户仍喜爱它。
5.操作符重载(operator overload)
我还要声明的是,前面定义的Add()函数,特别是为complex定做的那个,仍然是值得鄙弃的。它们虽然都能正常工作,但仍不是C++常用的风格。既然是求和,我们会更倾向于表达方式“complex c = c1 +c2;”而不是“complex c =Add(cl c2);”。
操作符’+’的使用要比Add ( )函数的调用让人舒服得多。C++中你完全可以摒弃所谓的“模板重置”,而直接对操作符’+’进行重载:
这样当出现。c1+ c2的形式时,表达式就会被赋予正当的含义。以下分述一些常见操作符的重载:
(1)单目操作符的重载:
设@为一个单目运算符,则@x和x@都被解释成operator @(x)。
瞧,这不就是函数调用的形式了吗?其中operator是C++的关键字。例如语句
y=--x;
将被译作
y = operator--(x);
下面是一个求复数相反数的例子:
假设complex的结构声明包含在complex. h头文件中,testl l将产生如下输出:
'++'和'--'亦可进行重载:
‘++’和’--’是一对怪东西,它们既可以作前缀,又可以作后缀。不过,以下形式的定义只适用于‘++’和’--’的后缀用法:
注意:其中操作int参数仅作为标志使用,而无其它含义。
(2)双目操作符的重载
设@为一个双目操作符,x@ y被解释成:
operator@(x y)
例如语句z=x+y;被译为z=operator+(x y);
毋需多言,前面的complex operator + (complex c1 complex c2)就是个很好的例子。
(3)new delete的重载
new delete也可以被重载(别看它们那样神秘),它们通常采取的声明形式如下:
void*operator new (size_t size);
void operator delete (void*p);
其中size t是一个与实现有关的unsigned int类型。以下是它们的使用:
int*ip=new int;
delete ip;
当使用new分配一个TYPE类型的对象空间时,sizeof (TYPE)将作为第一参数引起new (size_t)函数的调用,如上new语句将被译作:
ip=operator new (sizeof(int));
以下是重载的例子:
在这例子中,malloc()与free()被重新拾起,替代了new delete的功能。同时,new () delete()函数声明为static类型,以防止它们的重载对其它文件产生副作用。在未重载new、delete之前,系统会使用缺省的那一份new delete版本。
操作符重载是一张最令你自豪的Ace,但必须记住它仍具有以下限制:
①操作符重载要求操作对象至少有一个是类对象(类只是结构的一个广义概念)。我曾经做过以下的尝试:
但后来编译器证明了这种对基本数据类型的多情是愚蠢的。
②不可以构造新操作符,也不能改变操作符操作参数的数目,不能改变操作符的优先级。
③操作符的含义应尽量忠实于操作符的原义,这不是一条严格的规则,但是一条很好的忠告。譬如,当你将complex的’!’操作定义成机器重新启动的代码,虽然C++没有理由阻拦你,但这样不好。