VS C++编译时间过长的注意点
对于一个做端游的人来说，一般工程都是比较庞大的。对于编译链接花的时间有时候可以去做着喝几杯咖啡的时间浪费真是无语，还赶上有时候赶版本，真心很急…….虽然已经使用了必不可缺的IncrediBuild。
关于《C＋＋ codingStandards》以下几条整改原则:
关于include的原则最多，因为包含头文件相当于将代码复制到本文件来编译，而头文件又经常是用来被别人包含的，所以工程文件多了，每个文件都有include链（包含的文件又include了其他文件），该链条不会止步于你工程，而会延伸到你所有使用的第3方库里面。
1 能够去掉的include就去掉
（1）代码编写过程中或多或少都有一些历史遗留的不必要的头文件包含在你的文件里面，找到他们并去掉之。
（2）去掉include链里面重复的include。当然了, 有了 #ifndef …#define…#endif和#pragma once ，就算重复包含了，也只会包含编译一次了
2 能够在cpp里面include的头文件不要在头文件里面include。尽量去掉每个cpp会被串起来的头文件膨胀的机会。如果可以使用类声明的话，就不要用#include在头文件中。
关于《effective C++》条款34中将文件间的编译依存关系降至最低
1 如果可以使用对象的引用和指针，就要避免使用对象本身。定义某个类型的引用和指针只会涉及到这个类型的声明。定义此类型的对象则需要类型定义的参与。
尽可能使用类的声明，而不使用类的定义。因为在声明一个函数时，如果用到某个类，是绝对不需要这个类的定义的，即使函数是通过传值来传递和返回这个类，如：
classDate;
DatereturnADate();
void takeADate(Date d);
2 支持“编译依存性最小化”的一般构想是：相依于声明式，不要相依于定义式，基于此构想的两个手段是handle class & interface class;程序库头文件应该以”完全且仅有仅有声明式”的形式存在。一般讲C++设计的书中都会涉及到handle的设计理念，policy 策略，代理之类，必备知识~这个如果就开始来说，你可能就得多一层处理麻烦，可是对于工程大以及以后的用户（使用你写的类）来说，已经与底层一些类分割开了，没有了依存关系了。为了降低编译依赖性，我们只要知道这么一条就足够了：只要有可能，尽量让头文件不要依赖于别的文件；如果不可能，就借助于类的声明，不要依靠类的定义。一切方法都源于这一简单的设计思想。
关于inline的使用应该注意的
内联函数既能够去除函数调用所带来的效率负担又能够保留一般函数的优点。但是它不是任何情况下都是好的。
以下情况不宜使用内联：
1如果函数体内的代码比较长，使用内联将导致内存消耗代价较高。
2如果函数体内出现循环，那么执行函数体内代码的时间要比函数调用的开销大。类的构造函数和析构函数容易让人误解成使用内联更有效。要当心构造函数和析构函数可能会隐藏一些行为，如“偷偷地”执行了基类或成员对象的构造函数和析构函数。所以不要随便地将构造函数和析构函数的定义体放在类声明中。一个好的编译器将会根据函数的定义体，自动地取消不值得的内联。
关于不debug & release 版本区别
一个debug版可执行体要比release版大。那些额外的代码都是用来支持调试的，比如说符号的查找，比如一个inline函数，你会发现在debug下的反汇编还是当普通函数使用。但是，在release下，如果你的inline适合做为inline, 就可以看到它的反汇编是直接inline的。大多数实现都为debug版和release版提供了不同的operator new以及库函数。而且，一个release版的执行体可能已经通过多种途径进行了优化，包括不必要的临时对象的消除，循环展开，把对象移入寄存器，内联等等。有些情况下debug版可以正常报错，但是release不一定，如assert。所以为了都能正常执行就应该注意以下几点,不然让你花费额外的时间继续来处理一些不必要的麻烦：
1. 注意变量的初始化，尤其是指针变量，数组变量的初始化。（debug跟release在初始化变量时所做的操作是不同的）
2. 使用调试宏时使用后最好注释掉。
3. 尽量使用try - catch(...)
4. 尽量使用模块，不但表达清楚而且方便调试。
关于工作中遇到的情况
1 改变底层文件，就算你只是改变注释，也会导致从新编译，真是要命！
2 编译链接就算机器很新，最少也要花个几分钟，所以无论写代码的时候一定要做到全面检查，逻辑理清楚，争取一次性改好再编译，不要改一下，编译下，测试下，有问题，再改下，编译下……超花时间，当然了，经验多了，自然会好很多……
3 一个同事说过，感觉经常做的一样的事而抱怨，不是事情本身的问题，而是自己的问题，或许你可以尝试不同的方式来实现，就算不是真正在工程中用到，但也是一条不同道路，或者你可以弄个更通用的，反正看你做事的态度……so so