最近用到ucos，这个RTOS本身是用C语言和部分汇编编写，而自己又打算用C++来写应用，在其中遇到几个问题，一番折腾之后，让我更加深刻认识到了在一些一般不注意的细节上，C与C++的不同。
1、对于ucos，虽然我想Labrosse先生值得我们尊敬，为我们提供了ucos这么一个优秀的学习、应用RTOS的样本。但是我认为，Labrosse先生的C/C++语言功力还算不上炉火纯青。一个简单例子，在C中，右值无论是何种类型，皆可以强制转换为左值类型而不用强制说明（但最好自己声明转换）。ucos中大量的类型并没有手工声明转换类型，而恰恰C++中，这样是通不过编译的（除了基本类型转换）。这样，当我在工程中使用C++编译器来编译时，就会报告大量的类型转换出错。这个也许还算OK，自己一条一条加上就OK了。
2、对于第二个问题，这与Labrosse先生无关了，不过我还是被折腾好半天。当我修改好上面的问题后，编译再次出错，这次问题提示说，系统调度的一些核心函数没有定义。这我可晕了半天，找了大半天问题，除了发现这些报告未定义的函数都是出自于一个ASM汇编写的函数之外，似乎其他头绪了。这时候，我想，会不会是C编译器生成的目标文件的函数名与C++编译器生成的目标文件的函数名不同，因为ucos的C代码中会调用到ASM中的函数。于是，我自己用提供的C和C++编译器，分别对两段相同的函数文件（只是后缀名不同，一个C一个CPP）进行编译。果然不出所料，的确不同。例如我们在C/CPP中命名一个函数，例如 OSTickISR()，在C编译器生成的ASM中，名称是 _OSTickISR；在C++编译器生成的ASM中，名称是@OSTickISR$qv。而原ASM文件都是用C编译器一样的格式来声明的，所以以前直接用C编译能够正确，而现在换C++编译器就出错。
至此，我的代码终于能够顺利和修改后的ucos一起用C++编译器进行编译了。
以前我们区别C与C++的不同，主要还是集中例如面向对象，STL，Template等技术至上，对于这些小细节了解很少。通过这次的问题，让我更加深刻认识到，C++与C，在除了面向对象的层次上，还存在大量的不同，C++ is not a better C。
（该规范适用于Borland C++所带的编译器和链接器）
1、对于ucos，虽然我想Labrosse先生值得我们尊敬，为我们提供了ucos这么一个优秀的学习、应用RTOS的样本。但是我认为，Labrosse先生的C/C++语言功力还算不上炉火纯青。一个简单例子，在C中，右值无论是何种类型，皆可以强制转换为左值类型而不用强制说明（但最好自己声明转换）。ucos中大量的类型并没有手工声明转换类型，而恰恰C++中，这样是通不过编译的（除了基本类型转换）。这样，当我在工程中使用C++编译器来编译时，就会报告大量的类型转换出错。这个也许还算OK，自己一条一条加上就OK了。
2、对于第二个问题，这与Labrosse先生无关了，不过我还是被折腾好半天。当我修改好上面的问题后，编译再次出错，这次问题提示说，系统调度的一些核心函数没有定义。这我可晕了半天，找了大半天问题，除了发现这些报告未定义的函数都是出自于一个ASM汇编写的函数之外，似乎其他头绪了。这时候，我想，会不会是C编译器生成的目标文件的函数名与C++编译器生成的目标文件的函数名不同，因为ucos的C代码中会调用到ASM中的函数。于是，我自己用提供的C和C++编译器，分别对两段相同的函数文件（只是后缀名不同，一个C一个CPP）进行编译。果然不出所料，的确不同。例如我们在C/CPP中命名一个函数，例如 OSTickISR()，在C编译器生成的ASM中，名称是 _OSTickISR；在C++编译器生成的ASM中，名称是@OSTickISR$qv。而原ASM文件都是用C编译器一样的格式来声明的，所以以前直接用C编译能够正确，而现在换C++编译器就出错。
至此，我的代码终于能够顺利和修改后的ucos一起用C++编译器进行编译了。
以前我们区别C与C++的不同，主要还是集中例如面向对象，STL，Template等技术至上，对于这些小细节了解很少。通过这次的问题，让我更加深刻认识到，C++与C，在除了面向对象的层次上，还存在大量的不同，C++ is not a better C。
（该规范适用于Borland C++所带的编译器和链接器）
