应该是GCC没有进行inline（即使你写了inline，编译器也不保证进行inline），这样的话，到了链接阶段，对于A::print的引用，用哪个.o文件中的A::print都有可能（都是弱符号），但一定只会使用一个。

MinGW GCC 4.8.1没执行，所以impl1和impl2的生成的代码都是引用A::print这个符号，A::print的地址决断推迟到链接阶段（导出的应该是弱符号，所以不会报重定义错误，这点可以用objdump -t查看），使用哪一个cpp里提供的都有可能，所有打印impl1impl1或者impl2impl2都...

1和2貌似是一个问题。 o是operator++中的局部变量，如果返回对它的引用，在operator++结束后，该引用的值的是一个未定义行为，所以返回一份拷贝。 前置自增才返回引用，因为引用的是*this。

假设你获取到了一个char *的缓冲区，希望放到string里，那你可以这样： {代码...} 但是，我不知道这样做有什么好处。。

编译器能做的是尽量给你警告，我觉得标准没有规定test_3、test_6这样的行为必须给警告。

ct-submit is written in Go. Just run go build to build it. 没用过go，不确定它build出来的是否是Windows上的可执行程序。 Windows的命令行控制台中不用./，直接输入可执行程序名即可运行，如： {代码...} 如果这样不行的话，贴一下报错信息。 ----- Update -----...

检查下Windows防火墙（Windows防火墙->允许通过的程序）是否限制了FileZilla Server。

可能的情况：你本地有自己的修改，并且使用了git add && 你pull的内容与你的本地修改之间不存在任何的冲突。

打开一个控制台，执行VS目录/VC/下的vcvarsall.bat脚本设置环境变量，然后再试试buildwin 120。

其次，即使它们都有索引，还得和索引的类别结合起来（这一条我在实际开发中并没在意，因为涉及的应用都较小且基本没用过OR语句）。如果索引不是簇集索引又是范围查询的话，有时候使用索引的效率还不如顺序扫描全表，这时候DBMS可能就放弃使用索引了。