最近用到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++所帶的編譯器和鏈接器）
轉載于:https://www.cnblogs.com/leaway/archive/2006/04/27/386107.html
)
