27:尽量少做转型动作

news/2024/10/31 9:28:46/

转型(cast)破坏了类型系统。那可能导致任何种类的麻烦,有些容易辨识,有些非常隐晦。

一、转型语法 

(一)不同风格的语法

 1.C风格语法

C风格的转型动作:

(T)expression//将expression转型为T 

2.函数风格语法

函数风格的转型动作:

 T(expression)//将expression转型为T 

这两种形式并无差别,存粹只是小括号的摆放位置不同而已。称这两种形式为“旧式转型”(old-style cast)。

3.C++风格语法 

C++提供的四种新式转型(常常被称为new-style或C++-style cast):

1.const_cast<T>(expression)

2.dynamic_cast<T>(expression)

3.reinterpret_cast<T>(expression)

4.static_cast<T>(expression)

(二)C++风格语法详解 

上述四种转型方式各有不同的目的:

1.const_cast 

const_cast通常被用来将对象的常量性转除(cast away the constness)。它也是唯一有此能力的C++-style转型操作符。

2.dynamic_cast 

dynamic_cast主要用来执行“安全向下转型(safe downcasting)”,也就是用来决定某对象是否归属继承体系中的某个类型。它是唯一无法由旧式语法执行的动作,也是唯一可能耗费重大运行成本的转型动作。

3.reinterpret_cast 

reinterpret_cast意图执行低级转型,实际动作(及结果)可能取决于编译器,这也就表示它不可移植。例如,将一个pointer to int转型为一个int。

4.static_cast 

static_cast用来强迫隐式转换(implicit conversion),例如将non-const对象转为const对象,或将int转为double等等。它也可以用来执行上述多种转换的反向转换,例如将void*指针转为typed指针,将pointer-to-base转为pointer-to-derived。但它无法将const转为non-const——这个只有const_cast才办得到。

(三)尽量采用新式转型 

旧式转型仍然合法,但新式转型较受欢迎。原因是:

1.它们很容易在代码中被辨识出来(不论是人工辨识或使用工具如grep),因而得以简化“找出类型系统在哪个地点被破坏”的过程。

2.各转型动作的目标愈窄化,编译器愈可能诊断出错误的运用。例如若你打算将常量性去掉,除非使用新式转型中的const_cast否则无法通过编译。

二、转型的错误认识 

(一)转型做了某些动作 

某些程序员可能认为,转型其实什么都没做,只是告诉编译器把某种类型视为另一种类型。

这是错误的。任何一个类型转换(不论是通过转型操作而进行的显式转换,或通过编译器完成的隐式转换)往往真的令编译器编译出运行期间执行的码。

例如:

int x,y;
double d=static_cast<double>(x)/y;//x除以y,使用浮点数除法

 将int x转型为double几乎肯定会产生一些代码,因为在大部分计算器体系结构中,int的底层表述不同于double的底层表述。

又例如下面这个例子:

class Base{};
class Derived:public Base{};
Derived d;
Base* pb=&d;//隐喻地将Derived*转换为Base*

这里不过是建立一个base class指针指向一个derived class对象,但有时候上述的两个指针值并不相同。这种情况下会有个偏移量(offset)在运行期被施行于Derived*指针身上,用以取得正确的Base*指针值。

上个例子表明,单一对象(例如一个类型为Derived的对象)可能拥有一个以上的地址(例如“以Base*指向它”时的地址和“以Derived*”指向它时的地址。)实际上一旦使用多重继承,这事几乎一直发生着。即使在单一继承中也可能发生。

(二)不同语言的转型的适用性不同

另一件关于转型的事是:我们很容易写出某些似是而非的代码(在其他语言中也许真是对的)。

例如许多应用框架(appliciation framework)都要求derived class内的virtual函数代码的第一个动作就先调用base class的对应函数。假设有一个Window base class和一个SpecialWindow derived class,两者都定义了virtual函数onResize。进一步假设SpecialWindow的onResize函数被要求首先调用Window的onResize。

下面是实现方式之一,它看起来对,但实际上错:

class Window {
public:virtual void onResize(){}//base onResize实现代码
};
class SpecialWindow :public Window {
public:virtual void onResize() {//derived onResize实现代码static_cast<Window>(*this).onResize();//将*this转型为Window,//然后调用其onResize,//但这不可行//...//这里进行SpecialWindow专属行为}
};

上述程序将*this转型为Window,对函数onResize的调用也因此调用了Window::onResize。但实际上,他调用的并不是当前对象上的函数,而是稍早转型动作所建立的一个“*this对象的base class成分”的暂时副本身上的onResize。它不是在当前对象身上调用Window::onResize之后又在该对象身上执行SpecialWindow专属动作。它是在“当前对象的base class成分”的副本调用Window::onResize,然后在当前对象身上执行SpecialWindow专属动作。若Window::onResize修改了对象内容,当前对象其实没被改动,改动的是其副本。然而,若SpecialWindow::onResize内也修改对象,当前对象真的被改动。这将使当前对象进入一种“伤残”状态:其base class成分的更改没有落实,而derived class成分的更改落实了。

解决上述问题的方法是拿掉转型动作:

class SpecialWindow:public Window{
public:virtual void onResize(){Window::onResize();//调用Window::onResize作用于*this}
};

三、daynamic_cast探明

在探究dynamic_cast设计意涵之前,值得注意的是,dynamic_cast的许多实现版本执行速度相当慢。

例如,至少有一个很普遍的实现版本基于“class名称的字符串比较”,若你在四层深的单继承体系内的某个对象身上执行dynamic_cast,刚才说的那个实现版本所提供的每一次dynamic_cast可能会耗用多达四次的strcmp调用,用以比较class名称。深度继承或多重继承的成本更高。某些实现版本这样做有其原因(它们必须支持动态连接)。然而还是要强调,除了对一般转型保持机敏与猜疑,更应该注重效率的代码中对dynamic_cast保持机敏与猜疑。

之所以需要dynamic_cast,通常是因为你想在一个你认定为derived class对象身上执行derived class操作函数,但你的手上只有一个“指向base”的pointer或reference,你只能靠它们来处理对象。

有两个一般性做法可以避免这个问题。

(一)方法 

1.方法一

使用容器并在其中存储直接指向derived class对象的指针(通常是智能指针),如此便消除了“通过base class接口处理对象”的需要。

例如,假设先前的Window/SpecialWindow继承体系中只有SpecialWindow才支持闪烁效果,试着不要这样做:

class Window{};
class SpecialWindow :public Window {
public:void blink() {};
};
typedef std::vector<std::tr1::shared_ptr<Window>> VPW;int main()
{VPW winptrs;for (VPW::iterator iter = winptrs.begin(); iter != winptrs.end(); ++iter){//不希望使用dynamic_castif (SpecialWindow* psw = dynamic_cast<SpecialWindow*>(iter->get()))psw->blink();}return 0;
}

 应该这样做:

class Window{};
class SpecialWindow :public Window {
public:void blink() {};
};
typedef std::vector<std::tr1::shared_ptr<SpecialWindow>> VSPW;int main()
{VSPW winptrs;for (VSPW::iterator iter = winptrs.begin(); iter != winptrs.end(); ++iter){//不使用dynamic_cast(*iter)->blink();}return 0;
}

这种做法使你无法在同一个容器内存储指针“指向所有可能的各种Window派生类”。若真要处理多种窗口类型,你可能需要多个容器,它们都必须具备类型安全性(type-safe)。

2.方法二

第二种做法可让你通过base class接口处理“所有可能的各种Window派生类”。那就是在base class内提供virtual函数做你想对各个Window派生类做的事。

例如,虽然只有SpecialWindow可以闪烁,但或许将闪烁函数声明于base class内并提供一份“什么也没做”的缺省实现码是有意义的:

class Window{
public:virtual void blink(){}//缺省实现代码,//但在后面的章节会告诉你为什么缺省实现代码可能是个馊主意
};
class SpecialWindow :public Window {
public:virtual void blink() {};
};
typedef std::vector<std::tr1::shared_ptr<Window>> VPW;int main()
{VPW winptrs;for (VPW::iterator iter = winptrs.begin(); iter != winptrs.end(); ++iter){//注意,这里没有dynamic_cast(*iter)->blink();}return 0;
}

无论哪一种写法,都并非适用于所有情况,但在许多情况下它们都提供一个可行的dynamic_cast替代方案。

 (二)必须避免连串(cascading)dynamic_cast

绝对必须避免的一件事是所谓“连串(cascading)dynamic_cast”,也就是下述代码:

class Window{};
class SpecialWindow1 :public Window {
public:void blink() {};
};
class SpecialWindow2 :public Window {
public:void blink() {};
};
class SpecialWindow3 :public Window {
public:void blink() {};
};
typedef std::vector<std::tr1::shared_ptr<Window>> VPW;int main()
{VPW winptrs;for (VPW::iterator iter = winptrs.begin(); iter != winptrs.end(); ++iter){if(SpecialWindow1* psw1=dynamic_cast<SpecialWindow1*>(iter->get())){}if (SpecialWindow2* psw2 = dynamic_cast<SpecialWindow2*>(iter->get())) {}if (SpecialWindow3* psw3 = dynamic_cast<SpecialWindow3*>(iter->get())) {}}return 0;
}

这样产生出来的代码又大又慢,而且基础不稳,因为每次Window class继承体系一有改变,所有这一类代码都必须再次检阅看看是否需要修改。

例如,一旦加入新的derived class,或许上述连串判断中需要加入新的条件分支。这样的代码应该总是以某些“基于virtual函数调用”的东西取而代之。

就像面对众多蹊跷可疑的构造函数一样,我们应该尽可能隔离转型动作,通常是把它隐藏在某个函数内,函数的接口会保护调用者不受函数内部任何肮脏龌龊的动作影响。

四、总结

1.若可以,尽量避免转型,特别是在注重效率的代码中避免dynamic_cast。若有个设计需要转型动作,试着发展无需转型的替代设计。

2.若转型是必要的,试着将它隐藏于某个函数背后。客户随后可以调用该函数,而不需将转型放进他们自己的代码内。

3.宁可使用C++-style(新式)转型,不要使用旧式转型。前者很容易辨识出来,而且也比较有着分门别类的职掌。 


http://www.ppmy.cn/news/98661.html

相关文章

K8s in Action 阅读笔记——【5】Services: enabling clients to discover and talk to pods

K8s in Action 阅读笔记——【5】Services: enabling clients to discover and talk to pods 你已了解Pod以及如何通过ReplicaSets等资源部署它们以确保持续运行。虽然某些Pod可以独立完成工作&#xff0c;但现今许多应用程序需要响应外部请求。例如&#xff0c;在微服务的情况…

win10 nvprof的性能分析表

交叉访问是全局内存中最糟糕的访问模式&#xff0c;因为它浪费总线带宽 使用多个线程块对基于交叉的全局内存访问重新排序到合并访问 https://mp.weixin.qq.com/s/h2XKth1bTujnrxyXTJ2fwg <<<numBlocks, blockSize>>> 的两个参数应该怎么设置好呢。首先&…

Redis的SDS+IntSet+Dict

一)SDS 在redis中&#xff0c;保存key的是字符串&#xff0c;value往往是字符串或者是字符串的集合&#xff0c;可见字符串是redis中最常用的一种数据结构: 但是在redis中并没有直接使用C语言的字符串&#xff0c;因为C语言的字符串存在很多问题 1)获取字符串的长度需要通过运算…

stc15w404as使用keil做库,提供头文件,供调用

背景 有个项目使用需要使用库&#xff0c;将代码封装起来&#xff0c;仅仅留下调试接口&#xff0c;给用户使用&#xff0c;调试一些参数。这样工程看起来更简单&#xff0c;也方便客户维护。 也有一些使用场景&#xff0c;需要把自己的代码封装起来&#xff0c;这个是怕被别…

LeetCode 周赛 347(2023/05/28)二维空间上的 LIS 最长递增子序列问题

本文已收录到 AndroidFamily&#xff0c;技术和职场问题&#xff0c;请关注公众号 [彭旭锐] 提问。 往期回顾&#xff1a;LeetCode 单周赛第 346 场 仅 68 人 AK 的最短路问题 周赛 347 概览 T1. 移除字符串中的尾随零&#xff08;Easy&#xff09; 标签&#xff1a;模拟、…

HTTP协议深入理解+如何使用Fiddler抓包

博主简介&#xff1a;想进大厂的打工人博主主页&#xff1a;xyk:所属专栏: JavaEE初阶 目录 文章目录 一、HTTP概述 1.1 什么是HTTP 1.2 理解应用层协议 二、抓包工具fiddler的使用 2.1 几个需要注意的点 2.2 fiddler的原理 2.3 fiddler的使用技巧 三、HTTP请求&#xff08;Re…

第十六届全国大学生信息安全竞赛创新实践能力赛(CISCN)

目录 Misc 1、被加密的生产流量 Crypto 2、Sign_in_passwd Web 3、unzip 4、dumpit Re 5、babyRE Pwn 6、funcanary Misc 1、被加密的生产流量 下载附件解压后是一段流量&#xff0c;使用wireshark打开 最开始做的时候找错了方向&#xff0c;追踪到了另一个东西 …

Spark入门介绍

目录 一、Spark框架概述 1、Spark简介 2、发展 二、Spark功能及特点 1、定义