《C++覆辙录》——2.8:效果漂移的型别量化饰词

2.8:效果漂移的型别量化饰词

内建数组不可能有常量性或挥发性,所以修饰它的型别量化饰词(constvolatile)的效果实际上会漂移,转而应用到其持有物的某个适当位置:

typedef int A[12];
extern const A ca; // 由12个常量整数型别元素构成的数组
typedef int *AP[12][12];
volatile AP vm; // 指涉到整数型别元素的挥发性指针构成的二维数组```
volatile int *vm2[12][12]; // 指涉到挥发性整数型别元素的指针构成的二维数组
以上的解释合情合理,因为所谓数组,其名字的意义也不过就是指涉到其元素的指针。它本身并不占用存储,从而也谈不上什么常量性或挥发性这些和存储状态相关的概念,所以量化饰词的效果实际是应用到数组的元素上去了。不过要保持警惕,编译器经常对付不了太过复杂的情况。举例来说,`vm`的型别常常被编译器错误地解释成和`vm2`的型别是一样的21。

对函数声明的处理方式比较含糊。过去,一般的C++语言实现也允许相同的量化饰词效果漂移:

typedef int FUN(char *);
typedef const FUN PF; // 原先的情况:PF指涉到一个返回const int的函数
            // 现在:非法`
现在标准却说,应用于函数声明量化饰词只能用于声明一个“顶级”的  typedef,并且这个typedef还只能用于声明一个非静态的成员函数22:

typedef int MF() const;
MF nonmemfunc; // 错误!
class C{
  MF memfunc; // 没问题
};```
最好还是避免这种用法,当下的编译器并不能很好地理解它,而且它还会给维护工程师带来诸多困惑。
时间: 2024-09-20 11:45:14

《C++覆辙录》——2.8:效果漂移的型别量化饰词的相关文章

《C++覆辙录》——导读

前言 C++覆辙录 本书之渊薮乃是近20年的小小挫折.大错特错.不眠之夜和在键盘的敲击中不觉而过的无数周末.里面收集了普遍的.严重的或有意思的C++常见错误,共计九十有九.其中的大多数,(实在惭愧地说)都是我个人曾经犯过的. 术语"gotcha"1有其云谲波诡的形成历史和汗牛充栋的不同定义.但在本书中,我们将它定义为C++范畴里既普遍存在又能加以防范的编码和设计问题.这些常见错误涵盖了从无关大局的语法困扰,到基础层面上的设计瑕疵,再到源自内心的离经叛道等诸方面. 大约10年前,我开始在

《C++覆辙录》——第2章 语法问题2.1:数组定义和值初始化的语法形式混淆

第2章 语法问题 C++覆辙录C++语言的语法和词法结构博大精深.此复杂性的一部分是从C语言那里继承而来的,另一部分则是为支撑某些特定的语言特性所要求的. 本章中我们将考察一组语法相关的头疼问题.其中有些属于常见的手误,但是错误的代码仍然能够通过编译,只不过会以出人意料的方式运行罢了.另外一些则是由于一段代码的语法结构及它们的运行期行为不再互为表里.其余的部分,我们主要研究语法层面的灵活余地带来的问题:明明是一字不差的代码,不同的软件工程师能从中得出大相径庭的结论来. 2.1:数组定义和值初始化

《C++覆辙录》——常见错误1:过分积极的注释

第1章 基础问题 C++覆辙录 说一个问题是基础的,并不就是说它不是严重的或不是普遍存在的.事实上,本章所讨论的基础问题的共同特点比起在以后章节讨论的技术复杂度而言,可能更侧重于使人警醒.这里讨论的问题,由于它们的基础性,在某种程度上可以说它们普遍存在于几乎所有的C++代码中. 常见错误1:过分积极的注释 很多注释都是画蛇添足,它们只会让源代码更难读,更难维护,并经常把维护工程师引入歧途.考虑下面的简单语句: a = b; // 将b赋值给a 这个注释难道比代码本身更能说明这个语句的意义吗?因而

JS+CSS实现类似QQ好友及黑名单效果的树型菜单_javascript技巧

本文实例讲述了JS+CSS实现类似QQ好友及黑名单效果的树型菜单.分享给大家供大家参考.具体如下: 今天介绍的这个菜单堪称极品啊,不过里面的有些图标丢失了,路径还留在那,真想使用的朋友自己制作两个折叠菜单的图标按路径传上去就行了,这个菜单是模仿QQ面板的菜单功能,很多朋友还是很喜欢这种功能的,没想到用这么少的JS代码也可实现 ,值得代签哦. 运行效果截图如下: 在线演示地址如下: http://demo.jb51.net/js/2015/js-css-qq-hy-hmd-style-menu-c

《C++覆辙录》——1.5:对引用的认识误区

1.55:对引用的认识误区 对于引用的使用,主要存在两个常见的问题.首先,它们经常和指针搞混.其次,它们未被充分利用.好多在C++工程里使用的指针实际上只是C阵营那些老顽固的杰作,该是引用翻身的时候了. 引用并非指针.引用只是其初始化物的别名.记好了,能对引用做的唯一操作就是初始化它.一旦初始化结束,引用就是其初始化物的另一种写法罢了(凡事皆有例外,请看常见错误44).引用是没有地址的,甚至它们有可能不占任何存储: int a = 12; int &ra = a; int *ip = &r

《C++覆辙录》——1.9:使用糟糕的语言

1.9:使用糟糕的语言 当一个更大的世界入侵了C++社群原本悠然自得的乐土之时,它们带来了一些足堪天谴的语言和编码实践.本节乃是为了厘清返璞归真的C++语言所使用的正确适当.堪称典范之用语和行为. 用语 表1-1列出了最常见的用语错误,以及它们对应的正确形式. 表1-1 常见用语错误及其对应正确用语 没有什么所谓"纯虚基类".纯虚函数是有的,而包含有或是未能改写(override)此种函数的类,我们并不叫它"纯虚基类",而是叫它"抽象类". C+

《C++覆辙录》——1.3:全局变量

1.3:全局变量 很难找到任何理由去硬生生地声明什么全局变量.全局变量阻碍了代码重用,而且使代码变得更难维护.它们阻碍重用是因为任何使用了全局变量的代码就立刻与之耦合,这使得全局变量一改它们也非得跟着改,从而使任何重用都不可能了.它们使代码变得更难维护的原因是很难甄别出哪些代码用了某个特定的全局变量,因为任何代码都有访问它们的权限. 全局变量增加了模块间的耦合,因为它们往往作为幼稚的模块间消息传递机制的设施存在.就算它们能担此重任,从实践角度来说8,要从大型软件的源代码中去掉任何全局变量都几乎不

《C++覆辙录》——1.7:无视基础语言的精妙之处

1.7:无视基础语言的精妙之处 大多数C++软件工程师都自信满满地认为自己对所谓C++的"基础语言",也就是C++继承自C语言的那部分了如指掌.实际情况是,即使经验丰富的C++软件工程师,有时也会对最基础的C/C++语句和运算符的某些妙用一无所知. 逻辑运算符不能算难懂,对吗?但刚入行的C++软件工程师却总是不能让它们物尽其用.你看到下面的代码时是不是会怒从胆边生? bool r = false; if( a < b ) r = true;``` 正解如下: bool r = a

《C++覆辙录》——1.4:未能区分函数重载和形参默认值

1.4:未能区分函数重载和形参默认值 函数重载和形参默认值之间其实并无干系.不过,这两个独立的语言特征有时会被混淆,因为它们会模塑出语法上非常相像的函数用法接口.当然,看似一样的接口其背后的抽象意义却大相径庭: class C1 { public: void f1( int arg = 0 ); // ... };``` // ... C1 a; a.f1(0);a.f1();`型别C1的设计者决定给予函数f1()一个形参的默认值.这样一来,C1的使用者就有了两个选择:要么显式地给函数f1()一