本文发表在 rolia.net 枫下论坛首先声明，这是一个无聊的话题，绝不是什么学术研究。我本人没有抱严肃的态度，只是因为看见些奇谈怪论有些看不下去。
起因是这样一个论断：In the real world, C and C++ are different roles. C is faster than C++ ON SYSSTEM LEVEL for the reason that C doesn't have any the runtime feathers which are very important to C++。
我就奇了怪了，C怎么就能比C++快。语言之间的差异主要在描述能力上，性能上有差别主要是看不同的实现。同样是Basic，编译型远远快过解释型；同样是C，不同厂家的编译器、使用不同的编译选项，会有不同的性能。那C怎么快过C++的？
这位仁兄解释了半天也说不清楚，最后急了眼了终于祭出这个说法的原始出处，热烈欢迎：
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
恭请各位移驾，先去读读那篇文章，然后再回来。
那位老大是从4个方面论述的。
第一，C++的method多传递了一个指向当前对象的指针，所以might appear to be a big performance overhead。
多一个参数，就能有BIG overhead？翻译成汇编也不过就是前面多个push后面多个pop，怎么就BIG了？不知道他的逻辑是什么。不过这不重要，重要的是，指向当前对象的指针如果说作为一个隐含参数的话，它也是一个final的参数，在method内部是不会被改变的。也就是说，聪明的编译器完全可以不把它放进stack中！！这个overhead可能存在，但只存在于笨的编译器中，并且即使存在也不是什么big overhead。
第二，Object Construction
这个我刚开始没看懂，他说sometimes this might be an addition overhead。后来看懂了，他说This overhead can be reduced by defining the constructor inline。也就是说，这个overhead是一次函数调用的开销！也就是说，C可以直接写malloc而C++是一个函数调用！疯了... 如果这也叫C的速度优势的话，那写程序不要写函数调用，从头写到尾速度最快了！！
唉...编译器的优化可以搞定的东西。
第三，Object Destruction
这叫一个牵强啊！这个所谓的overhead是建立在C++的程序员写了不必要的distructor之上的。
第四，Static Access
恩？奇怪，他并没有说C++的overhead在哪，只说C++中这个method和class关联C中不关联。这倒是没有错，但是这个关联只是对编译器来说的，runtime没差。
好像还有之二。懒得看了，看不看都是类似的牛角尖。
关于第一点，如果哪位大侠比我还闲，可以把C++程序编译以后看看是不是真的多了个参数，开优化不开优化、不同的编译器有木有差别...如果还有时间，看看有没有选项把短的constructor自动inline。我自己没有这个条件，不好意思，我连编译器都没有，八百年没写C++啦更多精彩文章及讨论，请光临枫下论坛 rolia.net
起因是这样一个论断：In the real world, C and C++ are different roles. C is faster than C++ ON SYSSTEM LEVEL for the reason that C doesn't have any the runtime feathers which are very important to C++。
我就奇了怪了，C怎么就能比C++快。语言之间的差异主要在描述能力上，性能上有差别主要是看不同的实现。同样是Basic，编译型远远快过解释型；同样是C，不同厂家的编译器、使用不同的编译选项，会有不同的性能。那C怎么快过C++的？
这位仁兄解释了半天也说不清楚，最后急了眼了终于祭出这个说法的原始出处，热烈欢迎：
http://www.eventhelix.com/RealtimeMantra/basics/ComparingCPPAndCPerformance.htm
恭请各位移驾，先去读读那篇文章，然后再回来。
那位老大是从4个方面论述的。
第一，C++的method多传递了一个指向当前对象的指针，所以might appear to be a big performance overhead。
多一个参数，就能有BIG overhead？翻译成汇编也不过就是前面多个push后面多个pop，怎么就BIG了？不知道他的逻辑是什么。不过这不重要，重要的是，指向当前对象的指针如果说作为一个隐含参数的话，它也是一个final的参数，在method内部是不会被改变的。也就是说，聪明的编译器完全可以不把它放进stack中！！这个overhead可能存在，但只存在于笨的编译器中，并且即使存在也不是什么big overhead。
第二，Object Construction
这个我刚开始没看懂，他说sometimes this might be an addition overhead。后来看懂了，他说This overhead can be reduced by defining the constructor inline。也就是说，这个overhead是一次函数调用的开销！也就是说，C可以直接写malloc而C++是一个函数调用！疯了... 如果这也叫C的速度优势的话，那写程序不要写函数调用，从头写到尾速度最快了！！
唉...编译器的优化可以搞定的东西。
第三，Object Destruction
这叫一个牵强啊！这个所谓的overhead是建立在C++的程序员写了不必要的distructor之上的。
第四，Static Access
恩？奇怪，他并没有说C++的overhead在哪，只说C++中这个method和class关联C中不关联。这倒是没有错，但是这个关联只是对编译器来说的，runtime没差。
好像还有之二。懒得看了，看不看都是类似的牛角尖。
关于第一点，如果哪位大侠比我还闲，可以把C++程序编译以后看看是不是真的多了个参数，开优化不开优化、不同的编译器有木有差别...如果还有时间，看看有没有选项把短的constructor自动inline。我自己没有这个条件，不好意思，我连编译器都没有，八百年没写C++啦更多精彩文章及讨论，请光临枫下论坛 rolia.net