@YuJianrong 简而言之同一个翻译单元内违反ODR一般就是编译错误，然而不同翻译单元之间的不匹配并不要求检查(no diagnostics required)，所以可能链接出错也可能啥事没有但是就错的(ill-formed)，不能指望什么有合理的结果，于是炸了也活该——这部分相当于C的undefined behavior的一个子集（事实上ISO C也就直接明确类似的违反就是UB了）。于是实际上没法保证是否有这些情况，虽然我用过的靠谱的工具链一般是链接错误。

……嘛，严格来说是否有重复编译的冗余还是得看你调用编译器的方式。
如果直接扔给编译器驱动所有源文件，比如g++ test.cpp test2.cpp -otest，这样至少理论上还是能够优化的，虽然我实际上没看到这样的优化实现能明显改善（-flto倒是会调用make……）。
而如果非得g++ -c test.cpp -otest.o; g++ -c test2.cpp -otest2.o然后ld或者g++链接这些.o的话，就没救了，因为现在几乎所有系统上这样都是让每次翻译在单独的进程里跑，而除了链接时-flto这样的黑科技外我还没见到有神到会自主IPC优化的C++编译器……
（然而大部分现实项目都是后者的方式分批构建的，所以效率嘛。。反正make -j是救不了的。）

解决所有以上冗余的避免方法根本上都一样：把定义固定到确定的具体翻译单元中。然而这样会导致inline函数和模板的定义只有一个翻译单元能看得见，实际上没用。好在C++11引入了extern模板声明，允许显式指定不在当前翻译单元实例化，配合显式实例化就能基本消除这个开销（inline就看着办吧……）。
至于写头文件里会导致暴露实现，考虑到export这样的实现方式因为过于复杂、收益不够被毙了，是没办法解决的——根本上就是要标准化一种IL代替源码（反正得能让各家编译器都认识）表示实例化之前的东西，不可能是最终的目标代码，也就是五十步笑百步而已。
源码上只是要分离实现也不是不行，类似libstdc++这样把大段模板定义写到另外的文件里再包含，但技术上照样是头文件——只不过提醒用户没事别看罢了。当然写模板定义特别是类模板定义外的成员定义需要多几个template<>非常疼，自己看着办吧（反正我是没兴趣特别这样搞）。

@YuJianrong export只有EDG前端实现，而且C++11就移除了，关键字保留给以后用。

按照现在的编译器的一般实现基本不可能避免冗余。
不仅仅是模板，inline函数（不管最终是否被内联）、没有定义在翻译单元内的多态类的虚表（Clang++警告[-Wweak-vtables]）也是这样。
然而因为One Definition Rule的要求，链接时必须去除这些在不同翻译单元中完全相同的代码生成的相同的外部链接的实体。所以链接完以后的映像中是不会允许这些重复的定义。坏处主要是编译效率低下以及浪费空间：做了很多重复的无用功。
根本原因是C++的翻译链接模型是对称的，没有一个中心翻译单元。没有额外的特殊约定，编译器每次翻译过程中直接生成的目标二进制映像只对这一个一个翻译单元有意义，再次编译其它翻译单元时之前已经翻译好的目标代码不会被复用。于是对于头文件这种在预处理后每个翻译单元都有重复的东西，就只能重复翻译了。而跨翻译单元的优化也得推迟到链接时。

@durami 也不见得非得看书。了解一下算法分析的常识，然后找些自己有兴趣的实际问题解决。剩下的基础迟早会被逼得会用。

@durami 把二级忘掉，返工。
要算法之类的也不用太关注具体语言。

@Dongdong36 这人还曾公开喷GitHub除了code hosting以外（编辑，pr）几乎一无是处呢： https://github.com/torvalds/linux/pull/17。你确定跟这里那么多star党谈得拢么。

@dast B语言之父偷换成了Java之父……虽然都有偏执狂倾向但是等级完全不一样。有你这么黑的么。

@lijianying10 我对先前内容的正确性本身没有异议。但我不同意“毕竟传统的书籍都是串行算法，不适用当前的云时代了”这个说法——即便算法本身用不上，算法分析的一般方法、和实现结合的许多惯用法仍然都是相同或类似而可以参照的；而专门讲解并行算法的文献大多不会有耐心复述一遍这些较为经典的内容。
我同意你先前的回答可能会对不少人有帮助，不过从问题来看（正如你所说的“也许你提这个问题说明您是个初学者”），恐怕题主难以利用这些资源。
然而面向非初学者，问题涵盖的范围可以很大，方向也有很多，也并非一定侧重高性能计算。
所以我建议先缩小一下范围（或许可以让题主明确一下感兴趣的问题领域），以便更能有针对性。

@bwangel 逗号的功能不一定是“分隔语句”。
首先你得了解，C的语法中逗号并不都是一回事。有些逗号只是标点而不是操作符，如函数调用的postfix-expreesion中的分隔参数的逗号；而逗号表达式里的逗号操作符是另一回事。
最重要的影响语义的差异之一是，前者不限定求值顺序，而后者会插入一个sequence point。这里没有这个坑，但不知道迟早被坑。
语句之间是有sequence point的。从这个意义上来看，逗号操作符可以认为是在“分隔语句”。虽然实际上更像是个应付语句可用性缺陷设计的workaround（嘛，while条件里塞不进语句咋办……用逗号擦屁股吧）。而其它逗号，就显然不是这个意思。
printf("%d %d\n",(num=100,1),num);这坨里面，本来分号之前按postfix-expression来看，里面的逗号是argument-expression-list的组成部分——用于分隔作为参数assignment-expression的硬编码的分隔符而不是逗号操作符，但这里硬加了个括号，而作为argument的assignment-expression当然没法包括没配对的括号，语法分析就只能把(num=100,1)当作整个assignment-expression，然后继续规约：conditional-expression→...→primary-expression→( expression )→expression , assignment-expression——这里面的逗号就是逗号操作符了。
这里的要点是语法规则决定了assignment-expression的逗号不会被作为操作符，而加上括号以后括号里面的东西可以不是assignment-expression而是允许包含逗号操作符的一般expression，因此加上括号以后含义就变了。

@lijianying10 为什么关于C/C++算法，就需要参考侧重性能的具体实现呢？不管是不是初学者，如果根本没机会erformance tuning，研究这些材料投入和产出是不是会坑读者呢。即便是有这些需要，看这些之前，是不是先了解一些常见编译器选项和意义更实用呢？

@nilbot 对，这茬我倒给漏了。
嘛，一直觉得Ken这伙人taste奇葩倒罢了，还特么喜欢硬把自己的习惯加诸给用户。照抄保留下来的东西也经常贻害不浅，比如lvalue照样直接写进文法里而不是语义规则里搞得后面C（仍然是因为习惯而不便改动设计）还要返工，加上const里外不是人得刻意强调"modified" lvalue，还间接导致C++里面乱七八糟的value category的破事。

@lzjun C++14都正式版半年了……原版是Scheme么。

@MrGba2z Google的那啥C++规范，从目的（规范语用）来看内容写得极其外行，虽然其中有部分问题的辩解说是为了迁就小白用户和旧代码。（既然如此要你规范何用？）如果是写C++，在换行不换行以外的问题上强烈不建议参考。

@lilydjwg 好吧，漏了，\)的前面得是(for|while|if).+。我也不用单行块也不接受自己乱加;，所以没这类问题。
另外-Wall应该还是基于语义的，如果循环条件带副作用可能靠不住。

倒三角的评论应该分开回复……
GNU风格的最明显问题在于，它让制表符宽度一旦不是特定的一些预设值看起来就很糟糕，还不如都空格算了。

@chisj 都是习惯没错，但硬要说成一回事，“并没有什么好处”，不符合事实。
另起一行在习惯以外的好处，上面至少已经有人说了两个：人肉匹配块的边界更快；临时注释if等方便。（不管时常进行这些操作是不是习惯，对习惯或不习惯的用户来说效果应该都是类似的。）
而不另起一行的好处，也有提到了两个：节约行数；避免手贱错误地插入分号之类。
但是我已经指出过后者的这些理由很不一样：节约行数很不彻底，明显不如}}}}；即使能减少一些具有良好编码习惯的用户很少发生的输入错误，也远不如另外进行语法检查靠谱。
所以我仍然好奇习惯以外到底有什么决定性优点。

@lilydjwg 这种错误怎么看也没比自作主张脑补;的语言来得混乱。既然后者都能接受，前者又有啥大不了的呢。
真不爽的怕错的，直接禁止然后源码里正则暴搜干掉所有\);(?=\r?$)得了。这种检查还方便自动化实现。

倒三角形美观？完全不明觉厉。先看长的代码再看短的代码心情会好么。至少汉字的文章按这种构造写看起来挺奇怪的。

想要省空间省回车的，干脆就用没括号的算了。（虽然一写在纸上换页然后就容易呵呵了。）
要是不爽这坨，用Lisp风格不就行了，这不更节约行数么。
说到底凭什么}非得吊车尾而{就不行呢？完全没理性的理由，只是习惯罢了。基于}经常占据了单独的行这个现实，说节约行数是主要目的的，我很怀疑有没有花时间想过这里的问题。
另外，K&R也不是照搬的理由。注意一下K&R C函数体内部的块的{}和其它{}还不都一样，显然并不是任何时候都把{前的换行删除。另外值得一提的是，函数体层次上和内部块的{}风格不一样和函数体必须是复合语句这些artifacts现在看来都是K&R C旧参数声明语法的遗毒。

“我是个写了 10 年代码的码农，从来没有做过设计”
——你家的API spec是用膝盖糊出来还是天上掉下来的嘛？
平面设计？UI设计？工业设计？只是这些特例就想涵盖，也是醉了。

@mathgl 就算接口设计清楚点了，照样破事一堆。
比如Windows下Mercurial折腾exec bit，呵呵……都几年了才终于出来个官方workaround。
http://bz.selenic.com/show_bug.cgi?id=2020
另外基本实现不一样（revlog v. reflog），性能和可用性也不好说，得看日常哪些操作更多。

反正自己造的自己有数。
别人的先看看能不能抄，不方便抄的大多数情况也就说明不顶用了。