Effective C++ -----条款31：将文件间的编译依存关系降至最低

<Effective C++> 条款31:将文件间的编译依存关系降至最低 假设你对C++程序的某个class实现文件做了些轻微修改.注意,修改的不是class接口,而是实现,而且只改private成分.然后重新建置这个程序,预计只花数秒就好.毕竟只有一个class被修改.当你按下"Build"按钮或键入make指令时,会大吃一惊,然后感到困窘,因为你意识到整个世界都被重新编译个连接了!那么问题出在哪里呢??? 问题出在C++并没有把"将接口从实现中分离"

假如你在修改程序,只是修改了某个class的接口的实现,而且修改的是private部分.之后,你编译时,发现好多文件都被重新编译了.这种问题的发生,在于没有把"将接口从实现中分离".Class的定义不只是详细叙述class接口,还包括许多实现细目: class Person{ public: Person(const std::string& name, const Date& birthday, const Address& addr); std::strin

引言:编译时间成本 在项目中我们都会碰到修改既存类的情况:某个class实现文件做了些轻微改变,修改的不是接口,而是实现,而且只改private成分. 重新build这个程序,并预计只花数秒就好,当按下“Build”,结果整个世界都被重新编译和链接了! 问题是在c++并没有把“将接口从实现中分离”做得很好.class 的定义式不只详细叙述了class接口,还包括十足的实现细目: 例如: 1 class Person{ 2 public: 3 Person(const std::string& n

NOTE1: 1.支持“编译依存性最小化”的一般构想是:相依于声明式,不要相依于定义式.基于此构想的两个手段是Handle classes 和 Interface classes. 2.程序库头文件应该以“完全且仅有声明式”(full and declaration-only forms)的形式存在.这种不论是否涉及templates都适用.

本文为senlie原创,转载请保留此地址:http://blog.csdn.net/zhengsenlie 经验:支持"编译依存性最小化"的一般构想是:相依于声明式,不要相依于定义式. 基于此构想的两个手段是 Handle classes 和 Interface classes. 示例:相依于定义式 #include <string> #include "date.h" #include "address.h" class Perso

class Person { public: Person(const string& name, const Date& birthday, const Address& addr, const Country& country); virtual ~Person(); ... // 简化起见,省略了拷贝构造 // 函数和赋值运算符函数 string name() const; string birthDate() const; string address() cons

1. 假设要编写一个发生在太空的游戏,其中有飞船(spaceship),太空站(space station)和小行星(ssteroid),使它们继承自一个抽象基类GameObject,整个继承体系像这样: class GameObject { ... }; class SpaceShip: public GameObject { ... }; class SpaceStation: public GameObject { ... }; class Asteroid: public GameObj

***************************************转载请注明出处:http://blog.csdn.net/lttree******************************************** 五.Implementations Rule 31:Minimize compilation dependencies between files 规则 31:将文件间的编译依存关系降至最低 一.文件间的编译依存性 1.现象: 假设你对C++程序的某个class

一.类的实现面临的问题: 太快定义变量可能造成效率上的拖延:过度使用转型(casts)可能导致代码变慢又难维护,又招来微妙难解的错误:返回对象"内部数据之号码牌(handls)"可能会破坏封装并留给客户虚吊号码牌:为考虑异常带来的冲击则可能导致资源泄漏和数据败坏:过度热心地inlining可能引起代码膨胀:过度耦合则可能导致让人不满意的冗长建置时间. 二.条款26:尽可能延后变量定义式的出现时间 有些对象,你可能过早的定义它,而在代码执行的过程中发生了导常,造成了开始定义的对象并没有被