除非特别情况不要 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 可能是这种想法里设计的比较好的了。

理论上可以劫持 tcp 包，然后分析内容，如果是 ssh 协议，转发给 sshd ，如果是 http 协议，转发给 web service 。不知道有没人这么做过

https://github.com/owt5008137/libiniloader

自己写，带扩展语法的 ini 解析

不有源码吗？看源码呗

@daiv ok 。先 mark 一下，碰到需要的话我去瞧瞧看

@daiv 呦，这个也挺不错的。你这是要逆向它的协议吗？如果他有加密的话会很难搞。


我对 python 不熟呦，应该也会有类似 pcap 的 wraper 库吧，刚搜了下有 pypcap ，不知道是不是主流的抓包库。


实时更新数据和语言没什么关系哦。一般情况下就是两种，第一种 tcp 是双工的通道，可以直接推送。第二种就是心跳包，如果有数据的话心跳包的回包带回。


以前 webqq 就是第二种心跳包的形式，所以你会一直在抓包工具里看到心跳交互。你这个看起来也像心跳包，每次收到回包后 3 秒后发下一次心跳

@daiv 对的， websocket 也可以，我以前也看到过，没太注意忘记了。主要是 wensocket 的握手阶段也走的 http 协议

chrome 的开发工具和 fiddler 都只能抓 http 协议的，如果它 flash 里用原生 tcp 或者其他的就抓不到了，这时候只能 wireshark 啦，因为它直接抓网卡数据的。然后你需要学会怎么过滤指定端口或指定程序的数据包然后人工粘包。或者我们以前是写插件粘包和 dump 的