相当不错啊，不知道垃圾邮件过滤怎么样？因为我发现自建 mail 服务器似乎很容易收到垃圾邮件，而且 gmail 和 outlook 这方面都做得不错

首先要英语好，我看 paper 和文档的时候感觉最大的障碍就英语了。看中文翻译，即便翻译得不是特别好也是 2-3 倍的速度

基础 ok 了下面那些优先考虑的因素都是可以再细化再学的，方向性很强啊。
c++大部分也业务驱动的啊。
《 c++ primer plus 》只是本很基础的书，其他的他不都写明了么？编译原理方向，图像处理方向和并行计算方向。找 paper+读代码哇

无解啊，只要你看得到代码，再不济截屏复制图片到 onenote 然后点一下识别图中文本。就全出来了哇。
或者其他的图片识别的工具也行哇。
关键在于代码太容易识别了哇

@clino 我刚刚看了一下是有些项目用 rebase 合并 PR 的，但是自动的是没有 rebase 的。考虑到 code review 的话可能 rebase 的确会让分支看起来简单一些吧。其实比如上面我发的那个图， code review 的时候只看“与第 2 个父节点比较差异”的部分就可以了。因为“与第 1 个父节点比较差异”的内容是之前 review 过的（当然前提是如果每次 merge 都被 review 过）。不过我猜 gerrit 会强制你 rebase 可能是为了减少分支数。

@clino 按你们喜欢的方式来吧。本来这些个功能就是针对不同场景提供的。我不建议 rebase 是因为我以前也是默认开 rebase 的，但是碰到好几次一个 commit 要 rebase 好几次，而且 commit 数量稍微多一点就要我等好久，再加上碰到过好几次相同类型的冲突要解决好几次。不甚其烦，自从去掉 rebase 以后天下太平。而且如果不 rebase 首先就没有了 @leonlh 提的这个问题。只是个人建议而已。

@msg7086 我说的很多人不理解 git 工作流的理念的结果就是你说的很多人“跑来问我这货到底要怎么用”。所以我才说默认开 rebase 是妥协的结果。其他的不想浪费时间争论了，用你喜欢的方式吧，最顺手的才是最高效的。随便贴一个 github 上的项目的图吧。

http://i.imgur.com/3i6h2Lb.png

Vim 的优势就是不需要 GUI 哇，那么 ssh 到远程机器上的时候能省网速，且不需要远程服务器跑 GDM 啊之类的玩意儿。
Vim 的劣势就在没有 GUI 哇，那么最近比较火的 react 和 MVVM 都搞不了哇。而且配置起来烦得一腿。

@clino 所以我的回答里已经说了，每次拉取 rebase ，和 svn 相比优势也就剩下多分支了。缺点倒是多得一坨。

所谓 git 和 svn 的先进性相比，不是因为 git 比 svn 发明得晚，也不是它是 linus 发明的。而是它的工作方式和理念能解决实际的问题，这些实际的问题里，多分支 merge 是个比重比较高的点。只是多个 remote 的话用 svn 也不是很难解决，只是麻烦一点而已。

现在，其实很多人已经习惯了 svn ，经常容易拿 svn 的模式套在 git 上，导致很难理解这些理念，并且容易误操作。我的理念是，如果这些容易产生的误操作带来的解决问题的时间已经大于用 git 替换 svn 所节省的时间。那何必用 git 。难道只是很多人说 git 先进？先进的 scm 多了去了，和 git 相近的就有 hg ，为什么不用？还有 p4 ，为什么不用？

赞同 @xAx
@msg7086 我从来没说不要 rebase ，只是说尽量少用 rebase 。 history graph 里分支多有什么关系？ github 上分支多的开源项目多了去了。你看有几个 PR 会用 rebase 的？而且特别是性能问题，只有当你碰上复杂的多端合作开发，测试完成后一次 push 要合并很多 commit ，并且里面包含资源，你才能感受到 rebase 的局限性在哪

@msg7086 @clino
最简单地就是，如果尽量要 rebase ，为什么不用 svn ？而且 svn 原生就能版本精确到文件，不像 git 得拉取整个仓库，而且 rebase 的过程还巨慢无比（特别是变更多跨版本多的时候）。
难道仅仅是为了切分支不用换目录？@leonlh 合作开发需要设置多个 remote 的话想用 git 还勉强说得过去，但是也不是非要 rebase 啊。正常的 merge 完全可以。新版的 tortoisegit 为了提高 rebase 的速度，即便你选了 rebase ，在可以的情况也是用 merge 的。

另外回答下楼主的问题：高版本的（忘了哪个版本开始有的） git 的配置里，可以设置 automerge 和 autostash

我们这里除了非程序人员不会用 git ，为了让 git 尽量表现得像 svn 才给他们开 rebase ，程序一律走正常工作流，包括对外接入的东西。只是因为很多人已经被 svn 养成了习惯，不懂 git 的概念，导致很容易错误得 merge 才 rebase 的

@msg7086 分支管理不仅仅是指可以建多个分支，而是在存在多个分支的时候的一整套工作流。多分支之间的 merge 就是最重要的组成部分

除非特别情况不要 rebase ， git 最大的特色就是分支管理，动不动就 rebase 就完全失去了这个最重要的功能，那还不如回去用 svn 。

想要通用，看看 jemalloc 和 tcmalloc 的设计。然后参考它搞个适用你们项目的出来。
https://www.owent.net/QoH5w + 源码
其实现在的 ptmalloc 性能也挺不错的，前提是开编译优化以后

想要更高性能，自己做对象池。可以参考这个
https://github.com/owent-utils/c-cpp/blob/master/include/DataStructure/StaticIdxList.h
这是设计于用在共享内存里的，如果不需要支持共享内存可以参考这个
https://github.com/owent-utils/c-cpp/blob/master/include/DataStructure/DynamicIdxList.h

@Monad 我也赞同这种方法可控性更好。 TX 的 MMO 后台貌似都是这么做得

@xylophone21 是的。碰到同时存在动态库、静态库，然后又用像 cmake 或者 gyp 那种自动分析依赖关系的。确实容易一不留神就 GG 了。所以我现在项目里全部换成动态库了，省得再碰上这种糟心事儿。

@3dwelcome 是的，然而等我敲完上一条回复以后才看到后一条回复

@3dwelcome 关键不在于-rdynamic ，而是多个.so 之间或者.so 和可执行程序之间有相同的符号，最简单的构造方式就是链接相同的.a 或者编译进去相同的源文件。当项目结构复杂的时候除非强制依赖库全部用共享库，否则很难保证符号不重复。

libtest_c.so 的时候，不-ltest_a 倒是可以，但是这里的 sample 比较简单。如果这么做的话有两个前提
1. test_a 要编译成动态库
2. test_b 要把 libtest_a.so dlopen 进来。（意味着大型项目中可执行程序需要手动并按顺序把所有依赖的动态库 dlopen 进来）

如果不按上述方法做就可能碰到 https://www.owent.net/JqRzQ#comment-448 提到的问题。当然还有一种方法是链接选项里加上不裁剪未使用的符号，但是这样很会影响 LTO 。（不考虑每个模块需要手动精细地控制的情况）

另：我 blog 里的例子， b.cpp:18 改成 void* handle = dlopen("./libtest_c.so", RTLD_NOW|RTLD_GLOBAL);
编译选项改成：
gcc -O0 -g -ggdb a.cpp -o libtest_a.a -c -fPIC -rdynamic
gcc -O0 -g -ggdb b.cpp -o test_b -fPIC -ldl -L$PWD -ltest_a -lstdc++ -rdynamic
gcc -O0 -g -ggdb c.cpp -o libtest_c.so -shared -fPIC -L$PWD -ltest_a -lstdc++ -rdynamic

执行结果如下:
foo_class::foo_class(), this-> 0x602068
&foo_class::_ = 0x602068, foo_class::_.m = 1010
foo_class::foo_class(), this-> 0x602068
&foo_class::_ = 0x602068, foo_class::_.m = 110
foo_class::~foo_class(), this-> 0x602068
foo_class::~foo_class(), this-> 0x602068

我本地环境是 CentOS 7, GCC 4.8.5

@xylophone21 这里说的构造和析构指的是假如使用 C++的话， so 里的全局（包括静态）对象，不能有构造函数和析构函数，而不是指内存的分配操作。纯 C 或者 C++的 POD 类型的构造和析构是不会执行任何初始化操作和回收操作的，不会有问题。

具体指不要出现类似这样的代码:

```
void func() {
static int a = 123;
static CLASS obj(123,456);
}
```

其实这么说可能不是特别准确，因为如果全局（包括静态）对象如果只是在 so 内部使用，并不暴露给外部的话其实也并没什么大问题。这里这么说其实是设计上尽量避免问题出现的可能性。

因为既然是使用动态库做热更新，那不可避免地会出现多个 so 之间或者 so 和二进制之间会有相同的符号（包括引入了相同的源文件或者链接了相同的.a ），那么这些符号在所有的 so 里都会尝试执行一次实例化。

详见：
https://www.owent.net/JqRzQ
和
https://www.owent.net/Il9XS#坑二 linux 环境下共享静态库的问题

如果能解决好资源和对象的生命周期的管理问题。理论上是可以。

Windows 下，在一个 dll 里创建的对象，不能在另一个 dll 里释放。因为 Windows 下不同 dll 都有自己的堆。如果全局变量（包括单例）在 dll 里。那就要搞死人了。

Linux 下， so 里的全局变量（包括单例）不能有任何的启动初始化和卸载时析构（特别是用 C++的时候）。不然会对一个地址重复执行 ctor 和 dtor 。

其他的坑当然还有，诸如符号重复导入时的问题，接口版本不一致的问题等等。

好麻烦的说。 COM 可能是这种想法里设计的比较好的了。