读书笔记 effective c++ Item 31 把文件之间的编译依赖降到最低
1. 牵一发而动全身
现在开始进入你的C++程序,你对你的类实现做了一个很小的改动。注意,不是接口,只是实现,而且是private部分。然后你需要rebuild你的程序,计算着这个build应该几秒钟就足够了。毕竟,只修改了一个类。你点击了build 或者输入了make( 或者其他方式),你被惊到了,然后羞愧难当,因为你意识到整个世界都被重新编译和重新链接了!当这些发生时你不觉的感到愤恨么?
2. 编译依赖是如何发生的
问题出在C++并不擅长将接口从实现中分离出来。类定义不仅指定了类的接口也同时指定了许多类的细节。举个例子:
- class Person {
- public:
- Person(const std::string& name, const Date& birthday,
- const Address& addr);
- std::string name() const;
- std::string birthDate() const;
- std::string address() const;
- ...
- private:
- std::string theName; // implementation detail
- Date theBirthDate; // implementation detail
- Address theAddress; // implementation detail
- };
这里,类Person的实现需要使用一些类的定义,也就是string,Date,和Address,如果类Person对这些类的定义没有访问权,那么Person不会被编译通过。这些定义通过使用#include指令来提供,所以在定义Person类的文件中,你可能会发现像下面这样的代码:
- #include <string>
- #include "date.h"
- #include "address.h"
不幸的是,定义Person类的文件和上面列出的头文件之间建立了编译依赖。任何一个头文件被修改,或者这些头文件依赖的文件被修改,包含Person类的文件就必须要重新编译,使用Person的任何文件也必须要重新编译。这样的级联编译依赖会对一个工程造成无尽的伤痛。
3. 尝试将类的实现分离出来
你可能想知道为什么C++坚持将类的实现细节放在类定义中。举个例子,你为什么不能这么定义Person类,将指定类的实现细节单独分离开来。
- namespace std {
- class string; // forward declaration (an incorrect
- } // one — see below)
- class Date; // forward declaration
- class Address; // forward declaration
- class Person {
- public:
- Person(const std::string& name, const Date& birthday,
- const Address& addr);
- std::string name() const;
- std::string birthDate() const;
- std::string address() const;
- ...
- };
如果这是可能的 ,Person的用户只有在类的接口被修改的时候才必须要重新编译。
这个想法有两个问题。首先,string不是类,它是一个typedef(basic_string<char>的typedef)。因此,对string的前置声明是不正确的。合适的前置声明实质上更加复杂,因为它涉及到了额外的模板。然而这没关系,因为你不应该尝试对标准库的某些部分进行手动声明。相反,简单的使用合适的#include来达到目的。标准头文件看上去不像是编译的瓶颈,特别是你的编译环境允许你利用预编译头文件。如果标准头文件的解析真的是一个问题,你可能需要修改你的接口设计来避免使用标准库的某些部分(使用标准库的某些部分需要使用不受欢迎的#includes)。
对每件事情进行前置声明的第二个难点(并且是更加明显的)是需要处理如下问题:在编译过程中编译器需要知道对象的大小。考虑:
- int main()
- {
- int x; // define an int
- Person p( params ); // define a Person
- ...
- }
当编译器看到x的定义时,它们知道必须要为一个int分配足够的空间。这没问题。编译器知道一个int有多大。当编译器看到p的定义时,它们知道必须要为一个Person分配足够的空间,但是他们如何知道一个Person对象有多大呢?唯一的方法就是通过查看类定义,但是对于一个类的定义来说,如果将其实现细节忽略掉是合法的,编译器如何知道需要分配多少空间呢?
这种问题不会出现在像Smalltalk 和Java这样的语言中,因为当在这些语言中定义一个对象时,编译器只为指向对象的指针分配足够的空间。对于上面的代码,它们会像下面这样进行处理:
- int main()
- {
- int x; // define an int
- Person *p; // define a pointer to a Person
- ...
- }
这当然是合法的C++代码,所以你可以自己玩“将对象细节隐藏在指针后面”的游戏。对于Person来说,一种实现方式就是将其分成两个类,一个只提供接口,另一个实现接口。如果实现类的被命名为PersonImpl,Person将会被定义如下:
- #include <string> // standard library components
- // shouldn’t be forward-declared
- #include <memory> // for tr1::shared_ptr; see below
- class PersonImpl; // forward decl of Person impl. class
- class Date; // forward decls of classes used in
- class Address; // Person interface
- class Person {
- public:
- Person(const std::string& name, const Date& birthday,
- const Address& addr);
- std::string name() const;
- std::string birthDate() const;
- std::string address() const;
- ...
- private: // ptr to implementation;
- std::tr1::shared_ptr<PersonImpl> pImpl; // see Item 13 for info on
- }; // std::tr1::shared_ptr
这里,主类(Person)没有包含任何数据成员,只包含了指向类实现的指针(PersonImpl),一个tr1::shared_ptr指针(Item 13)。这样一个设计就是通常所说的“pimpl idiom”(指向实现的指针)。在这样的类中,指针的名字通常为pImpl,如上面所示。
使用这个设计,Person的用户脱离了datas,address和persons的实现细节。这些类的实现可以随意修改,但Person用户不需要重新编译。此外,因为他们不能够看到Person的实现细节,用户应该不会写出依赖这些细节的代码。这就对实现和接口进行了真正的分离。
4. 最小化编译依赖的设计策略
分离的关键在于把对定义的依赖替换为对声明的依赖。这是最小化编译依赖的本质:在切实可行的情况下让你的头文件能够自给自足,如果达不到这个要求,依赖其他文件中的声明而不是定义。其他的设计都来自于这个简单的设计策略。因此:
- 当使用指向对象的引用和指针能够做到时就不要使用对象。你可以只用一个声明来定义指向一个类型的引用和指针。而定义一个类型的对象则需要使用类的定义。
- 尽可能用类的声明替换类的定义。注意使用类来声明一个函数的时候你绝不会用到这个类的定义,甚至使用按值传递参数或者按值返回也不需要:
- class Date; // class declaration
- Date today(); // fine — no definition
- id clearAppointments(Date d); // of Date is needed
当然,按值传递通常情况下是一个坏方法(Item 20),但是如果你发现自己因为某种原因需要使用它,引入不必要的编译依赖也是没有任何理由的。
声明today和clearAppointments时不需要对Date进行定义可能会让你感到吃惊,但是它不像看上去那样让人好奇。如果任何人调用这些函数,Data的定义必须在函数调用之前被看到。你可能纳闷为什么声明无人调用的函数呢?很简单。不是没有人会调用它们,而是不是所有人都会调用它们。如果你有一个库包含很多函数声明,每个用户都调用每个函数是不太可能的。通过把在声明函数的头文件中提供类定义的责任转移到包含函数调用的客户文件中,你就消除了不必要的人为造成的对类型定义的用户依赖。
- 为声明和定义分别提供头文件
为了符合上述方针,头文件需要成对使用:一个用于声明,一个用于定义。当然这些文件应该保持一致。如果一个地方的声明被修改了,两个地方必须同时修改。最后,库的用户应该总是#include一个声明文件,而不是自己对其进行前向声明,。举个例子,Date类的客户想声明today和clearAppointments,这里就不用像上面那样对Date进行前向声明了。而是应该#include包含了声明的头文件:
- #include "datefwd.h" // header file declaring (but not
- // defining) class Date
- Date today(); // as before
- void clearAppointments(Date d);
头文件“datefwd.h”只包含声明,它的命名是基于标准C++库的头<iosfwd>(Item 54)。<iosfwd>包含了iostream组件的声明,与这些声明相对应的定义被放在几个不同的头中,包括<sstream>,<streambuf>,<fstream>和<iostream>。
<iosfwd>有另外一个指导性的意义,就是要弄清楚这个条款的建议不仅适用于templates,同样适用于非templates。虽然Item30解释了在许多编译环境中·,模板定义通常会放在头文件中,一些编译环境也允许将模板定义放在非头文件中,因此为模板提供只包含声明的头仍然是有意义的。<iosfwd>就是这样的头。
C++中同样提供了export关键字,它可以使模板声明从模板定义中分离出来。不行的是,支持export的编译器是稀少的,在现实世界中使用export的经验同样稀少。因此,评价
export会在高效C++编程中发挥什么作用还为时尚早。,
5. 句柄类
像Person这样使用了“指向实现的指针”(pimpl idiom)的类通常被叫做句柄类(handle class),如果你想知道这样的类是如何做到无所不能的,一种方法是将所有的函数调用转移到对应的实现类中,真正的工作在实现类中进行。举个例子,下面展示了Person类的两个成员函数是如何被实现的:
- #include "Person.h" // we’re implementing the Person class,
- // so we must #include its class definition
- #include "PersonImpl.h" // we must also #include PersonImpl’s class
- // definition, otherwise we couldn’t call
- // its member functions; note that
- // PersonImpl has exactly the same public
- // member functions as Person — their
- // interfaces are identical
- Person::Person(const std::string& name, const Date& birthday,
- const Address& addr)
- : pImpl(new PersonImpl(name, birthday, addr))
- {}
- std::string Person::name() const
- {
- return pImpl->name();
- }
注意Person构造函数是如何调用PersonImpl构造函数的(通过使用new Item 16),以及Person::name是如何调用PersonImpl::name的,这很重要。将Person类定义成句柄类并没有改变Person类能做什么,只是修改了Person类做什么的实现方式。
6. 抽象基类
使用句柄类的另外一种替代方法是将Person定义成特殊的抽象基类,也就是接口类。使用这种类的意图是为派生类指定一个接口(Item 34)。这种类没有数据成员,没有构造函数,有一个虚析构函数(item7)和一系列纯虚函数。
接口类同Java和.NET中的接口是类似的,但Java和.NET对接口强加了限制,c++却没有这做。举个例子,Java和.NET都不允许在接口中声明数据成员或者实现函数,但C++对这两者都没有限制。C++的这种更强的灵活性是有用的。在Item36中解释道,在一个继承体系中应该为所有类实现相同的非虚函数,因此对于在接口类中被声明的函数,作为接口类的一部分对其进行实现是有意义的。
一个Person类的接口实现可能像下面这个样子:
- class Person {
- public:
- virtual ~Person();
- virtual std::string name() const = ;
- virtual std::string birthDate() const = ;
- virtual std::string address() const = ;
- ...
- };
这个类的用户必须依靠Person指针或者引用来进行编程,因为不可能实例化包含纯虚函数的类。(然而实例化Person的派生类却是可能的)。就像句柄类的用户一样,接口类只有在其接口发生变化的情况下才需要重新编译,其它情况都不需要。
一个接口类的用户必须要有创建新对象的方法。通常情况下,这通过调用扮演派生类构造函数角色的函数来实现,当然派生类是可以被实例化的。这样的函数通常被叫做工厂函数(Item13)或者虚构造函数(virtual constructors)。它们返回指向动态分配对象的指针(用智能指针比较好Item 18)。这样的函数在接口类中通常被声明为static:
- class Person {
- public:
- ...
- static std::tr1::shared_ptr<Person> // return a tr1::shared_ptr to a new
- create(const std::string& name, // Person initialized with the
- const Date& birthday, // given params; see Item18 for
- const Address& addr); // why a tr1::shared_ptr is returned
- ...
- };
用户像下面这样使用:
- std::string name;
- Date dateOfBirth;
- Address address;
- ...
- // create an object supporting the Person interface
- std::tr1::shared_ptr<Person> pp(Person::create(name, dateOfBirth, address));
- ...
- std::cout << pp->name() // use the object via the
- << " was born on " // Person interface
- << pp->birthDate()
- << " and now lives at "
- << pp->address();
- ... // the object is automatically
- // deleted when pp goes out of
- // scope — see Item13
当然,必须定义支持接口类接口的具现类,并且在具现类中必须调用真正的构造函数。这在包含了虚构造函数实现的文件中都会发生。举个例子:Person接口类可能有一个具现化派生类RealPerson,它为继承自基类的虚函数提供了实现:
- class RealPerson: public Person {
- public:
- RealPerson(const std::string& name, const Date& birthday,
- const Address& addr)
- : theName(name), theBirthDate(birthday), theAddress(addr)
- {}
- virtual ~RealPerson() {}
- std::string name() const; // implementations of these
- std::string birthDate() const; // functions are not shown, but
- std::string address() const; // they are easy to imagine
- private:
- std::string theName;
- Date theBirthDate;
- Address theAddress;
- };
给出RealPerson的定义后,实现Person::create就变得微不足道了:
- std::tr1::shared_ptr<Person> Person::create(const std::string& name,
- const Date& birthday,
- const Address& addr)
- {
- return std::tr1::shared_ptr<Person>(new RealPerson(name, birthday,
- addr));
- }
Person::create的一个更加现实的实现是创建不同的派生类对象,对象类型可能会依赖于额外的函数参数,从文件或者数据库中读取的数据或环境变量等等。
实现一个接口类有两个最普通的机制,RealPerson展示出了其中的一个:它的接口继承自接口类(Person),然后在接口中实现函数。实现接口类的第二种方法涉及到多继承,在Item40中会涉及到这个话题。
7. 使用接口类和句柄类需要花费额外的开销
句柄类和接口类将接口从实现中解耦出来,从而减少了文件间的编译依赖。你可能会问,这种伎俩会让我付出什么?答案也是计算机科学中的常见回答:它会让运行时速度变慢,
另外会为每个对象分配额外的空间。
在句柄类的例子中,成员函数必须通过指向实现的指针才能到达对象数据。这为每次访问添加了一个间接层。你必须将这个实现指针的大小添加到存储每个对象需要的内存容量上。最后,实现指针必须被初始化为指向动态分配的实现对象,因此你引入了动态分配内存(还有接下来的内存销毁)所固有的开销,还有可能遇到的bad_alloc(内存溢出)异常。
对接口类来说,每次函数调用都是virtual的,所以在你每次调用一个函数的时候,都会有一次间接跳转的开销(Item 7)。同时,从接口类中派生出来的对象必须包含一个虚表指针(Item7)。这个指针可能会增加对象存储需要的内存容量,取决于接口类是否为此对象提供虚函数的唯一来源。
最后,脱离inline函数句柄类和接口类都不会有很大作为。Item30解释了为什么函数体必须要放在头文件中从而被inline,但是句柄和接口类正是用来设计隐藏像函数体一样的实现细节的。
如果你仅仅因为额外的开销就放弃使用句柄类和接口类就大错特错了。虚函数也是如此,你并不想放弃它们,对吧?(如果想放弃,你看的书就是错误的)相反,使用一种循序渐进的方式来使用它们。在开发过程中使用接口类和句柄类最小化修改实现造成的对用户的影响。如果使用句柄类和接口类对速度和容量造成的影响要大于类之间的耦合,那么用具现类进行替换。
8. 总结:
最小化编译依赖背后的知道思想是依赖于声明而不是依赖于定义。基于这个思想的方法是句柄类和接口类。
库头文件应该以完全且仅有声明的方式存在。不管是否涉及到模板都适用。
读书笔记 effective c++ Item 31 把文件之间的编译依赖降到最低的更多相关文章
- 读书笔记 effective c++ Item 23 宁可使用非成员非友元函数函数也不使用成员函数
1. 非成员非友元好还是成员函数好? 想象一个表示web浏览器的类.这样一个类提供了清除下载缓存,清除URL访问历史,从系统中移除所有cookies等接口: class WebBrowser { pu ...
- 读书笔记 effective c++ Item 29 为异常安全的代码而努力
异常安全在某种意义上来说就像怀孕...但是稍微想一想.在没有求婚之前我们不能真正的讨论生殖问题. 假设我们有一个表示GUI菜单的类,这个GUI菜单有背景图片.这个类将被使用在多线程环境中,所以需要mu ...
- 读书笔记 effective c++ Item 39 明智而谨慎的使用private继承
1. private 继承介绍 Item 32表明C++把public继承当作”is-a”关系来对待.考虑一个继承体系,一个类Student public 继承自类Person,如果一个函数的成功调用 ...
- 读书笔记 effective c++ Item 25 实现一个不抛出异常的swap
1. swap如此重要 Swap是一个非常有趣的函数,最初作为STL的一部分来介绍,它已然变成了异常安全编程的中流砥柱(Item 29),也是在拷贝中应对自我赋值的一种普通机制(Item 11).Sw ...
- 读书笔记 effective c++ Item 34 区分接口继承和实现继承
看上去最为简单的(public)继承的概念由两个单独部分组成:函数接口的继承和函数模板继承.这两种继承之间的区别同本书介绍部分讨论的函数声明和函数定义之间的区别完全对应. 1. 类函数的三种实现 作为 ...
- 读书笔记 effective C++ Item 40 明智而谨慎的使用多继承
1. 多继承的两个阵营 当我们谈论到多继承(MI)的时候,C++委员会被分为两个基本阵营.一个阵营相信如果单继承是好的C++性质,那么多继承肯定会更好.另外一个阵营则争辩道单继承诚然是好的,但多继承太 ...
- 读书笔记 effective c++ Item 55 让你自己熟悉Boost
你正在寻找一个高质量的,开源的,与平台和编译器无关的程序库的集合?看一下Boost吧.想加入一个由雄心勃勃的,充满天赋的正致力于最高水平的程序库设计和实现工作的C++程序员们组成的团体么?看一下Boo ...
- 读书笔记 effective c++ Item 11 在operator=中处理自我赋值
1.自我赋值是如何发生的 当一个对象委派给自己的时候,自我赋值就会发生: class Widget { ... }; Widget w; ... w = w; // assignment to sel ...
- 读书笔记 effective c++ Item 30 理解内联的里里外外 (大师入场啦)
最近北京房价蹭蹭猛涨,买了房子的人心花怒放,没买的人心惊肉跳,咬牙切齿,楼主作为北漂无房一族,着实又亚历山大了一把,这些天晚上睡觉总是很难入睡,即使入睡,也是浮梦连篇,即使亚历山大,对C++的热情和追 ...
随机推荐
- MySQL ibdata多路径扩容
vi /etc/my.cnf innodb_data_home_dir = innodb_data_file_path= /data/mysql/ibdata1:10M:autoextend(为目前i ...
- [心得]传统IT转互联网面试经验分享
http://www.newsmth.net/bbstcon.php?board=Java&gid=374779 传统IT外企干了8年,两年前转互联网的,面的和被面的都不少.这几天项目空档期, ...
- Wireshark对常见视频应用的抓包分析的结果
一.PC端直播: YY客户端直播用的udp(P2P)9158客户端直播用的rtp/rtcp 二.Web端直播: YY网页端直播用的tcp9158网页端直播用的tcp六间房网页端直播用的tcp17173 ...
- html标签大全(1)
http标签详解及讲解 1.基础标签 <!DOCTYPE html> <!--表示文本类型--> <html> <!--<html> ...
- 将 ext_net 连接到 router - 每天5分钟玩转 OpenStack(145)
上一节完我们创建了外部网络 ext_net,接下来需要将其连接到 Neutron 的虚拟路由器,这样 instance 才能访问外网. 点击菜单 Project -> Network -> ...
- 三层——vb.net版
经过不懈的努力,我的vb.net 版的三层登陆终于实现了.下面将我的成果向大家展示一下. 原则 vb.net的三层登陆跟C#的三层登陆的思想是一样的都是将系统分层--U层只负责与用户 ...
- java批量爬去电影资源
摘要 网上有很多个人站来分享电影资源,其实有时候我们自己也想做这个一个电影站来分享资源.但是这个时候就有一个问题,电影的资源应该从哪里来呢?难道要自己一条条手动去从网络上获取,这样无疑是缓慢而又效率低 ...
- matlab中运用项目思维分析问题并解决问题
我们将沿着以下几步思考:1.State the problem关于这个例子陈述问题很简单.我们想写一个判定二元一次方程的程序:是否有两个实根,重复实根,或者两个复数根2.Define the inpu ...
- ubuntu下包管理器apt-get常用命令
apt-cache search package 搜索包 apt-cache show package 获取包的相关信息,如说明.大小.版本等 sudo apt-get install package ...
- [css 揭秘]:CSS揭秘 技巧(三):背景定位
我的github地址:https://github.com/FannieGirl/ifannie 源码都在这上面哦! 喜欢的给我一个星吧 背景定位 问题:很多时候,我们想针对容器某个角对背景图片做便宜 ...