為什麼工控還在用c?

01-21

最近編stm32，發覺類真是個好東西，c裡面用結構體寫真是快哭了，結構體裡面調函數還要用指針，真是難用，我只知道貌似dsp什麼的用的是c++，keil下有辦法用c++么？c有存在的必要性么？

工控很多還在用彙編呢……

對於工控設備而言，最重要的是穩定，所以你看vxwork一類的程序，都是純彙編實現，因為這樣可以實現完全的時間/運行規則可預知。舉個例子，兩台工控，輸入一樣的情況下，內存數據應該是完全一致的。而C++，甚至是C所引入的眾多feature都是導致潛在不穩定的源泉

關於Keil的問題……這玩意只是個IDE，順便附帶了Realview編譯器，可以換GCC系，就是需要自己寫編譯腳本了。

And... C++在STM32中早就已經廣泛應用了...從MBED到~巴拉巴拉

關於C有沒有存在的必要....年輕人= =，哪天你能說我熟練掌握C的時候，估計才有資格討論這個問題。

keil可以用C++

首先對主程序文件右鍵進入選項卡，改文件類型為C++ Source file。後綴名不必改，雖然是.c，但是會按C++文件編譯。

然後到項目選項里添加--CPP，就會按C++編譯編譯文件了，還要勾選C99 Mode，C的部分才會按C99編譯，否則C的部分會按C89編譯，有些隱式類型轉換會出錯，需要強制類型轉換才行。之後就可以C++和C混編了，STM32的hal庫雖然都是C編寫的，但是都做好了C++混編的處理，不影響調用函數庫。

這樣改過之後就可以用C++了，如果不用類、不用C++抽象手段，只用C的語法，其實不容易發現這個是C++文件，也就是說改用C++並不會帶來不方便的地方，畢竟C++是C的一個超集。而且假若在C++中只寫C的語法，這個運行效率其實是一樣的，如果在C中實現跟C++一樣的抽象，同樣也會損耗一些性能，代碼的複雜度還會更高。

在C++中可以只用C的面向過程開發，達到C的效率，也可以添加類實現基於對象開發，也可以為了更高的開發效率用面向對象開發，後果就是損失性能。完全可以按照項目需要採用不同的開發方式。

但是C++可以內嵌C，C卻不能內嵌C++，也就是說用C寫的代碼有更廣的移植性，所以STM32的函數庫還是用C編寫的。

是啊，明明實時系統應該用彙編的，居然用C，工作是不想幹了了是吧！

因為高級語言控制硬體不方便，同樣是串口同樣波特率c#比c或者cpp cpu高，c#中位元組轉換成int或uint什麼的反編譯之後都是直接對內存操作的，類似c++，只是封裝了一下，c#不滿足很多工程要求，比如自帶的timer最小17ms左右觸發一次，工程要求1khz時根本做不到。同樣的功能用delphi或者labview就可以實現，對ad採樣即使while（true）也只有 667hz左右無法滿足工程要求，所以你如果用了高級語言你會發現更坑。

補充一下，操作系統分實時操作系統和非實時操作系統，實時操作系統可以準確計算出執行某操作所需的準確時間，就像51的彙編知道晶振頻率已經所執行的指令的機器周期後可以準確的計算所寫代碼執行的事件，而這是非實時操作系統不具備的，而工控對實時要求往往很高

C比C++好用

keil能用C++開發stm32，C有存在的意義。

當然有啦，C 快呀，不複雜，所以統一功能拿不同語言實現，一定是越底層的代碼實現起來效率高。越是低端（比如8位MCU）越是要用C寫，甚至彙編；高端（比如STM32）就開始用一些抽象化來讓編程的人感覺舒服一點，因為MCU的性能能負擔得起帶來的壞處。

Keil好像不能用C++，不過STM32用C也是挺好的挺舒服的呀