文档章节

C++批判(3)

rise-worlds
 rise-worlds
发布于 2016/06/20 13:42
字数 1440
阅读 0
收藏 0
保证类型安全的联结属性(type-safe linkage)

 C++ARM中解释说type-safe linkage并不能100%的保证类型安全。既然它不那100%的保证类型安全,那么它就肯定是不安全的。统计分析显示:即便在很苛刻的情况下,C++ 出现单独的O-ring错误的可能性也只有0.3%。但我们一旦将6种这样的可能导致出错的情况联合起来放在一起,出错的几率就变得大为可观了。在软件中,我们经常能够看到一些错误的起因就是其怪异的联合。OO的一个主要目的就是要减少这种奇怪的联合出现。
 
 大多数问题的起因都是一些难以察觉的错误,而不是那些简单明了的错误导致问题的产生。而且在通常的情况下,不到真正的临界时期,这样的错误一般都很难被检测到,但我们不能由此就低估了这种情况的严肃性。有许多的计划都依赖于其操作的正确性,如太空计划、财政结算等。在这些计划中采用不安全的解决方案是一种不负责任的做法,我们应该严厉禁止类似情况的出现。
 
 C++在type-safe linkage上相对于C来说有了巨大的进步。在C中,链接器可以将一个带有参数的诸如f(p1,...)这样的函数链接到任意的函数f()上面,而这个 f()甚至可以没有参数或是带有不同的参数都行。这将会导致程序在运行时出错。由于C++的type-safe linkage机制是一种在链接器上实做的技巧,对于这样的不一致性,C++将统统拒绝。
 
 C++ARM将这样的情况概括如下--“处理所有的不一致性->这将使得C++得以100%的保证类型安全->这将要求对链接器的支持或是机制(环境)能够允许编译器访问在其他编译单元里面的信息”。
 
  那么为什么市面上的C++编译器(至少AT&T的是如此)不提供访问其他毕业单元中的信息的能力呢?为什么到现在也没有一种特殊的专门为C++设计的链接器出现,可以100%的保证类型安全呢?答案是C++缺乏一种全局分析的能力(在上一节中我们讨论过)。另外,在已有的程序组件外构造我们的系统已经是一种通用的Unix软件开发方式,这实现了一定的重用,然而它并不能为面向对象方式的重用提供真正的弹性及一致性。
 
 在将来, Unix可能会被面向对象的操作系统给替代,这样的操作系统足够的“开放”并且能够被合适地裁剪用以符合我们的需求。通过使用管道(pipe)及标志 (flag),Unix下的软件组件可以被重复利用以提供所需的近似功能。这种方法在一定的情况下行之有效,并且颇负效率(如小型的内部应用,或是用以进行快速原型研究),但对于大规模、昂贵的、或是对于安全性要求很高的应用来说,采取这样的开发方法就不再适合了。在过去的十年中,集成的软件(即不采用外部组件开发的软件)的优点已经得到了认同。传统的Unix系统不能提供这样的优点。相比而言,集成的系统更加的复杂,对于开发它们的开发人员有着更多的要求,但是最终用户(end user)要求的就是这样的软件。将所有的东西拙劣的放置于一起构成的系统是不可接受的。现在,软件开发的重心已经转到组件式软件开发上面来了,如公共领域的OpenDoc或是Microsoft的OLE。
 
 对于链接来说,更进一步的问题出现在:不同的编译单元和链接系统可能会使用不同的名字编码方式。这个问题和type-safe linkage有关,不过我们将会在“重用性及兼容性”这节讲述之。
 
 Java使用了一种不同的动态链接机制,这种机制被设计的很好,没有使用到Unix的链接器。Eiffel则不依赖于Unix或是其他平台上的链接器来检测这些问题,一切都由编译器完成。
 
 Eiffel 定义了一种系统层上的有效性(system-level validity)。一个Eiffel编译器也就因此需要进行封闭环境下的分析,而不是依赖于链接器上的技巧。你也可以就此认为Eiffel程序能够保证 100%的类型安全。对于Eiffel来说有一个缺点就是,编译器需要干的事情太多了。(通常我们会说的是它太“慢”了,但这不够精确)目前我们可以通过对于Eiffel提供一定的扩展来解决这个问题,如融冰技术(melting-ice technology),它可以使得我们对于系统的改动和测试可以在不需要每次都进行重新编译的情况下进行。
 
 现在让我们来概括一下前两个小节 - 有两个原因使我们需要进行全局(或封闭环境下的)分析:一致性检测及优化。这样做可以减掉程序员身上大量的负担,而缺乏它是C++中的一个很大的不足。

本文转载自:http://www.cnblogs.com/flying_bat/archive/2007/09/28/909198.html

rise-worlds

rise-worlds

粉丝 3
博文 1755
码字总数 0
作品 0
深圳
程序员
私信 提问
别再批判c++,因为没意义

首先任何一门语言都有局限性,c++有其使用场景 其次大部分说c++复杂的人,根本发现不了c++的美,甚至有一大部分人根本没使用过c++ 最后B.S. 说c++不好,那是大师说不好,和有些人说c++不好有...

2011/11/15
3.2K
27
VC++之MFC的五大批判

VC++之MFC的五大批判 写在本文之前算起来,我用Visual C++也有将近5年的历史了。在这期间,我也曾涉猎过Visual Basic和Delphi,但都是浅尝而止;Visual C++始终是我的主业。可是努力的成果如...

长平狐
2013/01/06
358
0
叫板C++之ACE,哈,大家进来围观!!

首先,大家热烈讨论是对的,真理不辩不明,而且真理不会天然的站在任何人一边。 其次,我仍然抱着我的观点,C++用来实现ACE本身 是一种设计思维错误。我始终认为就ACE官网所想描述的内容,不...

中山野鬼
2012/04/28
6K
53
Qt设计模式(第二版):谁最需要本书?

情人节前夕,突然受邀作为本书中文版的审校,心中在惊喜之余,也有些诚惶诚恐。能与闫老师(yfx2003)合作,共同学习与探讨,确是一件幸事;但是自己真的能胜任该工作么?一开始心里还真是没底...

晨曦之光
2012/05/08
2.7K
0
为什么我希望用C而不是C++来实现ZeroMQ(第二篇)

译注:这篇文章可能又会引起 C++ 程序员的诸多不适,就作者本文所描述的问题来看,某些“C++的问题”其实是可以有C++的解决方案的。请参阅侵入式和非侵入式容器。但是考虑到ZeroMQ是一个很底...

开心303
2012/09/12
389
2

没有更多内容

加载失败,请刷新页面

加载更多

golang-字符串-地址分析

demo package mainimport "fmt"func main() {str := "map.baidu.com"fmt.Println(&str, str)str = str[0:5]fmt.Println(&str, str)str = "abc"fmt.Println(&s......

李琼涛
今天
4
0
Spring Boot WebFlux 增删改查完整实战 demo

03:WebFlux Web CRUD 实践 前言 上一篇基于功能性端点去创建一个简单服务,实现了 Hello 。这一篇用 Spring Boot WebFlux 的注解控制层技术创建一个 CRUD WebFlux 应用,让开发更方便。这里...

泥瓦匠BYSocket
今天
6
0
从0开始学FreeRTOS-(列表与列表项)-3

FreeRTOS列表&列表项的源码解读 第一次看列表与列表项的时候,感觉很像是链表,虽然我自己的链表也不太会,但是就是感觉很像。 在FreeRTOS中,列表与列表项使用得非常多,是FreeRTOS的一个数...

杰杰1号
今天
4
0
Java反射

Java 反射 反射是框架设计的灵魂(使用的前提条件:必须先得到代表的字节码的 Class,Class 类 用于表示.class 文件(字节码)) 一、反射的概述 定义:JAVA 反射机制是在运行状态中,对于任...

zzz1122334
今天
5
0
聊聊nacos的LocalConfigInfoProcessor

序 本文主要研究一下nacos的LocalConfigInfoProcessor LocalConfigInfoProcessor nacos-1.1.3/client/src/main/java/com/alibaba/nacos/client/config/impl/LocalConfigInfoProcessor.java p......

go4it
昨天
9
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部