編寫高效簡(jiǎn)潔的c語言代碼

編寫高效簡(jiǎn)潔的c語言代碼，是許多軟件工程師追求的目標(biāo)。本文就工作中的一些體會(huì)和經(jīng)驗(yàn)做相關(guān)的闡述，不對(duì)的地方請(qǐng)各位指教。

第 1 招：以空間換時(shí)間

計(jì)算機(jī)程序中最大的矛盾是空間和時(shí)間的矛盾，那么從這個(gè)角度出發(fā)逆向思維來考慮程序的效率問題，我們就有了解決問題的第1招--以空間換時(shí)間。

例如：字符串的賦值。

從上面的例子可以看出，A和 B的效率是不能比的。在同樣的存儲(chǔ)空間下，B直接使用指針就可以操作了，而 A 需要調(diào)用兩個(gè)字符函數(shù)才能完成。B的缺點(diǎn)在于靈活性沒有 A好。在需要頻繁更改一個(gè)字符串內(nèi)容的時(shí)候，A 具有更好的靈活性；如果采用方法 B，則需要預(yù)存許多字符串，雖然占用了大量的內(nèi)存，但是獲得了程序執(zhí)行的高效率。

如果系統(tǒng)的實(shí)時(shí)性要求很高，內(nèi)存還有一些，那我推薦你使用該招數(shù)。該招數(shù)的邊招--使用宏函數(shù)而不是函數(shù)。舉例如下：

函數(shù)和宏函數(shù)的區(qū)別就在于，宏函數(shù)占用了大量的空間，而函數(shù)占用了時(shí)間。大家要知道的是，函數(shù)調(diào)用是要使用系統(tǒng)的棧來保存數(shù)據(jù)的，如果編譯器里有棧檢查選項(xiàng)，一般在函數(shù)的頭會(huì)嵌入一些匯編語句對(duì)當(dāng)前棧進(jìn)行檢查；同時(shí)，CPU也要在函數(shù)調(diào)用時(shí)保存和恢復(fù)當(dāng)前的現(xiàn)場(chǎng)，進(jìn)行壓棧和彈棧操作，所以，函數(shù)調(diào)用需要一些CPU時(shí)間。而宏函數(shù)不存在這個(gè)問題。宏函數(shù)僅僅作為預(yù)先寫好的代碼嵌入到當(dāng)前程序，不會(huì)產(chǎn)生函數(shù)調(diào)用，所以僅僅是占用了空間，在頻繁調(diào)用同一個(gè)宏函數(shù)的時(shí)候，該現(xiàn)象尤其突出。

D方法是我看到的最好的置位操作函數(shù)，是 ARM 公司源碼的一部分，在短短的三行內(nèi)實(shí)現(xiàn)了很多功能，幾乎涵蓋了所有的位操作功能。C方法是其變體，其中滋味還需大家仔細(xì)體會(huì)。

第 2 招：數(shù)學(xué)方法解決問題

現(xiàn)在我們演繹高效C 語言編寫的第二招--采用數(shù)學(xué)方法來解決問題。數(shù)學(xué)是計(jì)算機(jī)之母，沒有數(shù)學(xué)的依據(jù)和基礎(chǔ)，就沒有計(jì)算機(jī)的發(fā)展，所以在編寫程序的時(shí)候，采用一些數(shù)學(xué)方**對(duì)程序的執(zhí)行效率有數(shù)量級(jí)的提高。

舉例如下，求 1～100 的和。

這個(gè)例子是我印象最深的一個(gè)數(shù)學(xué)用例，是我的計(jì)算機(jī)啟蒙老師考我的。當(dāng)時(shí)我只有小學(xué)三年級(jí)，可惜我當(dāng)時(shí)不知道用公式 Nx（N+1）/2來解決這個(gè)問題。方法E 循環(huán)了 100次才解決問題，也就是說最少用了 100個(gè)賦值、100個(gè)判斷、200個(gè)加法（I和 j）；而方法F僅僅用了 1 個(gè)加法、1個(gè)乘法、1 次除法。效果自然不言而喻。所以，現(xiàn)在我在編程序的時(shí)候，更多的是動(dòng)腦筋找規(guī)律，最大限度地發(fā)揮數(shù)學(xué)的威力來提高程序運(yùn)行的效率。

第 3 招：使用位操作

實(shí)現(xiàn)高效的C 語言編寫的第三招--使用位操作，減少除法和取模的運(yùn)算。在計(jì)算機(jī)程序中，數(shù)據(jù)的位是可以操作的最小數(shù)據(jù)單位，理論上可以用“位運(yùn)算”來完成所有的運(yùn)算和操作。一般的位操作是用來控制硬件的，或者做數(shù)據(jù)變換使用，但是，靈活的位操作可以有效地提高程序運(yùn)行的效率。舉例臺(tái)如下：

在字面上好象 H比G麻煩了好多，但是，仔細(xì)查看產(chǎn)生的匯編代碼就會(huì)明白，方法 G調(diào)用了基本的取模函數(shù)和除法函數(shù)，既有函數(shù)調(diào)用，還有很多匯編代碼和寄存器參與運(yùn)算；而方法H則僅僅是幾句相關(guān)的匯編，代碼更簡(jiǎn)潔、效率更高。當(dāng)然，由于編譯器的不同，可能效率的差距不大，但是，以我目前遇到的MS C，ARM C來看，效率的差距還是不小。相關(guān)匯編代碼就不在這里列舉了。運(yùn)用這招需要注意的是，因?yàn)?CPU 的不同而產(chǎn)生的問題。比如說，在 PC 上用這招編寫的程序，并在 PC 上調(diào)試通過，在移植到一個(gè) 16位機(jī)平臺(tái)上的時(shí)候，可能會(huì)產(chǎn)生代碼隱患。所以只有在一定技術(shù)進(jìn)階的基礎(chǔ)下才可以使用這招。

第 4 招：必殺技——嵌入?yún)R編

“在熟悉匯編語言的人眼里，C語言編寫的程序都是垃圾”。這種說法雖然偏激了一些，但是卻有它的道理。匯編語言是效率最高的計(jì)算機(jī)語言，但是，不可能靠著它來寫一個(gè)操作系統(tǒng)吧？所以，為了獲得程序的高效率，我們只好采用變通的方法--嵌入?yún)R編、混合編程。

舉例如下，將數(shù)組一賦值給數(shù)組二，要求每一個(gè)字節(jié)都相符。char string1［1024］， string2［1024］;

方法 I是最常見的方法，使用了 1024次循環(huán)；方法J則根據(jù)平臺(tái)不同做了區(qū)分，在 ARM 平臺(tái)下，用嵌入?yún)R編僅用 128次循環(huán)就完成了同樣的操作。這里有朋友會(huì)說，為什么不用標(biāo)準(zhǔn)的內(nèi)存拷貝函數(shù)呢？這是因?yàn)樵谠磾?shù)據(jù)里可能含有數(shù)據(jù)為0 的字節(jié)，這樣的話，標(biāo)準(zhǔn)庫(kù)函數(shù)會(huì)提前結(jié)束而不會(huì)完成我們要求的操作。這個(gè)例程典型應(yīng)用于 LCD數(shù)據(jù)的拷貝過程根據(jù)不同的 CPU，熟練使用相應(yīng)的嵌入?yún)R編，可以大大提高程序執(zhí)行的效率。

雖然是必殺技，但是如果輕易使用會(huì)付出慘重的代價(jià)。這是因?yàn)?，使用了嵌入?yún)R編，便限制了程序的可移植性，使程序在不同平臺(tái)移植的過程中，臥虎藏龍、險(xiǎn)象環(huán)生！同時(shí)該招數(shù)也與現(xiàn)代軟件工程的思想相違背，只有在迫不得已的情況下才可以采用，切記。

這么說教太枯燥了，更多內(nèi)容歡迎q一起討論3250395686我們來看一個(gè)例子。以一個(gè)LED 閃爍的程序?yàn)槔?/p>

＃include《reg52.h》//包含頭文件

復(fù)制代碼

這是指示燈LED 閃爍的C 源碼，這個(gè)源碼在Keil UVision4 生成的程序代碼是67 個(gè)字節(jié)。下面就采用幾個(gè)方法來提高這個(gè)程序的效率。

1、盡量定義局部變量

單片機(jī)程序的全局變量一般是放在通用數(shù)據(jù)存儲(chǔ)器（RAM）中，而局部變量一般是放在特殊功能寄存器當(dāng)中。處理寄存器數(shù)據(jù)的速度比處理RAM 數(shù)據(jù)要快，如果在一個(gè)局部函數(shù)里調(diào)用一個(gè)全局變量將會(huì)多生成好幾個(gè)代碼出來。所以，少定義全局變量，多定義局部變量。如上例中，如果把延時(shí)函數(shù)里的i 和j 定義為全局變量，編譯后程序代碼會(huì)增加到79 個(gè)字節(jié)，多了12 個(gè)字節(jié)。

2、省略函數(shù)定義

在一個(gè)單片機(jī)程序里我們習(xí)慣在main 函數(shù)的前面先定義被調(diào)用函數(shù)，然后在mian 函數(shù)的下面再實(shí)現(xiàn)被調(diào)用函數(shù)。這樣的寫法固然是一個(gè)好習(xí)慣，但每定義一個(gè)函數(shù)會(huì)增加幾個(gè)代碼，而且函數(shù)形參數(shù)據(jù)類型越大、形參越多增加的代碼就越多，顯然這不是什么好事。如果不定義編譯器又報(bào)錯(cuò)，怎么辦？C 編譯器的編譯順序是從上往下編譯，只要被調(diào)用的函數(shù)在主調(diào)函數(shù)調(diào)用之前實(shí)現(xiàn)就沒有問題了。所以，筆者的習(xí)慣寫法是不用定義函數(shù)，但要按先后順序（被調(diào)用函數(shù)一定要在主調(diào)函數(shù)之前寫好）來寫函數(shù)實(shí)現(xiàn)，到最后再寫main 函數(shù)。這樣做編譯器不但不會(huì)報(bào)錯(cuò)，而且代碼得到精簡(jiǎn)了。如上例中，把延時(shí)函數(shù)的定義刪除了，然后把延時(shí)函數(shù)的實(shí)現(xiàn)搬到main 函數(shù)的上面，編譯后程序代碼減少到63 個(gè)字節(jié)，減少了4 個(gè)字節(jié)。

3、省略函數(shù)形參

函數(shù)帶形參，是為了在函數(shù)調(diào)用時(shí)傳遞實(shí)參，不但可以避免重復(fù)代碼出現(xiàn)，還可以通過傳遞不同的實(shí)參值多次調(diào)用函數(shù)且實(shí)現(xiàn)不同的函數(shù)功能，總體代碼也會(huì)得到精簡(jiǎn)。在實(shí)際編程的時(shí)候，我們只要注意，還可以進(jìn)一步精簡(jiǎn)代碼。對(duì)于不是多次調(diào)用或者多次調(diào)用但實(shí)參值不變的函數(shù)我們可以省略函數(shù)形參。如上例中的延時(shí)函數(shù)，我們把它改成不帶形參的函數(shù)：

void Delayms（）//延時(shí)函數(shù){unsigned int i，j;for（i=0;i《500;i++）for（j=0;j《120;j++）;//大約延時(shí)1 毫秒}

編譯后，程序代碼變成了56 個(gè)字節(jié)，精簡(jiǎn)了11 個(gè)字節(jié)。

4、改換運(yùn)算符

也許您可能沒有注意到C 運(yùn)算符的運(yùn)用也會(huì)影響程序代碼的數(shù)量。如上例中，把延時(shí)函數(shù)里的自加運(yùn)算符改成自減運(yùn)算符后，如：

void Delayms（unsigned int t）//延時(shí)函數(shù){unsigned int i，j;for（i=t;i》0;i--）for（j=120;j》0;j--）;//大約延時(shí)1 毫秒}

編譯后，程序代碼變成了65 個(gè)字節(jié)，精簡(jiǎn)了2 個(gè)字節(jié)。

通過改換運(yùn)算符能達(dá)到精簡(jiǎn)代碼的例子還有：

⑵ ⑷把求余運(yùn)算表達(dá)式改為位與運(yùn)算表達(dá)式。如：b=a%8 可以改為：b=a&7。

⑵ 把乘法運(yùn)算表達(dá)式改為左移運(yùn)算表達(dá)式。如：b=a*8 可以改為：b=a《《3。

⑶ 把除法運(yùn)算表達(dá)式改為右移運(yùn)算表達(dá)式。如：b=a/8 可以改為：b=a》》3。

5、選擇合適的數(shù)據(jù)類型

C 語言里選擇變量的數(shù)據(jù)類型很講究，變量的數(shù)據(jù)類型過小滿足不了程序的要求，變量的數(shù)據(jù)類型過大會(huì)占用太多的RAM 資源。您可能還沒有注意到數(shù)據(jù)類型定義也影響程序代碼的大小，而且這個(gè)影響還不小。如上例中，延時(shí)函數(shù)里的局部變量j 定義的數(shù)據(jù)類型明顯偏大，如果把它由unsigned int 改成unsigned char 。編譯后，程序代碼變成了59 個(gè)字節(jié)，精簡(jiǎn)了8 個(gè)字節(jié)。

6、直接嵌入代碼

在您的程序里如果某個(gè)函數(shù)只調(diào)用一次，而您又要求代碼提高執(zhí)行速度，建議您不要采用調(diào)用函數(shù)的形式，而應(yīng)該將該函數(shù)里的代碼直接嵌入主調(diào)函數(shù)里，代碼執(zhí)行效率會(huì)大大提高。

7、使用效率高的C 語句

C 語言里有一個(gè)三目運(yùn)算符“？”，俗稱“問號(hào)表達(dá)式”。很多程序員都很喜歡使用，因?yàn)樗壿嬊逦磉_(dá)簡(jiǎn)潔。

看這個(gè)問號(hào)表達(dá)式：c=（a》b） ？ a+1 ： b+1;實(shí)際上等效于以下的IF…else 結(jié)構(gòu)：

if （a》b） c=a+1;else c=b+1;

可以看到，使用問號(hào)表達(dá)式，語句相當(dāng)簡(jiǎn)潔，但它的執(zhí)行效率卻很低，遠(yuǎn)沒有if…else 語句效率高。所以，當(dāng)您的程序要求提高執(zhí)行速度的話，建議您不要使用問號(hào)表達(dá)式了。

另外，do…while 語句也比while 語句的效率高。

代碼的效率問題，不是我們編程中的主要問題，除了程序要求較高的執(zhí)行速度或者單片機(jī)的ROM 和RAM 不夠用的時(shí)候才會(huì)考慮。一般情況下，我們不用在乎。如果您一味追求高效率的代碼，可能會(huì)影響代碼的可讀性和可維護(hù)性。