軟件|曾讓你哭笑不得抓狂的C語言知識(shí)點(diǎn)
回復(fù)【經(jīng)典電路】,獲取5000個(gè)經(jīng)典電路
回復(fù)【論文】,獲取畢業(yè)設(shè)計(jì)、電子競(jìng)賽、學(xué)術(shù)專業(yè)等相關(guān)論文資料回復(fù)【電容】,獲取電容、元器件選型相關(guān)的內(nèi)容;
回復(fù)【阻抗匹配】,獲取電磁兼容性、阻抗匹配相關(guān)的資料回復(fù)【資料】,獲取全部電子設(shè)計(jì)、單片機(jī)開發(fā)相關(guān)的資料回復(fù)【終端電阻】,獲取CAN終端電阻相關(guān)的資料回復(fù)【單片機(jī)】,獲取單片機(jī)全套視頻教程和參考設(shè)計(jì)
…………
歡迎關(guān)注【玩轉(zhuǎn)單片機(jī)與嵌入式】公眾號(hào)。本公眾號(hào)會(huì)以連載的形式推出一系列關(guān)于STM32學(xué)習(xí)的教程,歡迎關(guān)注。
1.關(guān)于 =以及-=
?這是兩個(gè)運(yùn)算符,但你否有過這種經(jīng)歷:1.?int?temp;??2.?char?i??3.?for(i=0;i
2.?關(guān)于意想不到的死循環(huán)1.??unsigned?char?i;??2.???for(i=0;i<256;i )??3.???{??4.??????????//something??5.???} ?當(dāng)我們用上述代碼想實(shí)現(xiàn)一個(gè)小循環(huán)時(shí),結(jié)果卻事與愿違,這其實(shí)是死循環(huán)的另一種寫法,因?yàn)闊o符號(hào)變量i最大只有255,要命的是,編譯器并不會(huì)指出這個(gè)錯(cuò)誤。
與之相類似的代碼是:1. ?unsigned char i;??2.???for(i=10;i>=0;i--)??3.???{??4.????????//something??5.???} ?這也是一個(gè)死循環(huán),你看出什么原因了嗎?無論i如何減,i都是大于等于0的。? ? ? ?這就告訴我們對(duì)于每個(gè)變量類型的取值范圍要由清醒的認(rèn)識(shí)。值得注意的是相同的變量類型對(duì)于不同的CPU構(gòu)架和不同的編譯器會(huì)有不同的結(jié)果。比如int類型在大多數(shù)16位CPU構(gòu)架中占用兩個(gè)字節(jié),但在32位CPU中卻往往占用4個(gè)字節(jié);char類型在絕大多數(shù)編譯器中都是有符號(hào)數(shù),但在keil MDK中卻是無符號(hào)數(shù),若是要在keil MDK下定義有符號(hào)char類型變量,必須用signed顯式聲明。我曾讀過一本書,其中有一句話:“signed關(guān)鍵字也是很寬宏大量,你也可以完全當(dāng)它不存在,在缺省狀態(tài)下,編譯器默認(rèn)數(shù)據(jù)位signed類型”,這句話便是有異議的,我們應(yīng)該對(duì)自己所用的CPU構(gòu)架以及編譯器熟練掌握。
3.?關(guān)于'='和'=='1.?if(Value=0x01)??2.?{??3.???????//something??4.?} ?當(dāng)我們判斷一個(gè)變量是否等于0x01時(shí),你是否也寫過類似上面的代碼?C語言的創(chuàng)造者認(rèn)為賦值運(yùn)算符"="出現(xiàn)的概率要遠(yuǎn)遠(yuǎn)大于等于運(yùn)算符"==",因此,我們正常邏輯中的"等于"符號(hào)(=)在C語言中成了賦值運(yùn)算符,而C語言的"等于"運(yùn)算符卻被兩個(gè)等于號(hào)(==)所代替。我之所以對(duì)這個(gè)事件耿耿于懷是因?yàn)槲以诖蠖臅r(shí)候參加的C 二級(jí)上機(jī)考試,當(dāng)我感覺很輕松的做完最后一道題后,卻發(fā)現(xiàn)運(yùn)算的結(jié)果卻與邏輯相悖,經(jīng)過調(diào)試發(fā)現(xiàn),有一個(gè)條件一直為真,我檢查了很多遍才發(fā)現(xiàn)出問題的邏輯將等于運(yùn)算符寫成了賦值運(yùn)算符。在if語句中給變量賦一個(gè)非零值,也難怪這個(gè)邏輯總是為真。??編譯器同樣不對(duì)這個(gè)問題做出指導(dǎo)性建議,值得一提的是,如果你在Keil的if語句中使用了賦值運(yùn)算符,編譯器會(huì)給出警告。? ? ? ?避免這個(gè)問題的一個(gè)很好的辦法是使用良好編程習(xí)慣,比如上面的代碼可寫為:1.?if(0x01==Value)??2.?{??3.???????//something??4.} ?將常量值放到變量的前面,即使將等于運(yùn)算符寫成賦值運(yùn)算符,編譯器也能產(chǎn)生一個(gè)語法錯(cuò)誤,因?yàn)閷⒁粋€(gè)變量賦值給一個(gè)常量是非法的。
4.?error:?#7:?unrecognized?token? ? ? ?我在剛使用C語言以及Keil編譯器時(shí),對(duì)于這個(gè)編譯器錯(cuò)誤,有很深的印象。出現(xiàn)這個(gè)編譯錯(cuò)誤的典型代表是在敲代碼的時(shí)候輸入了中文標(biāo)點(diǎn)??!
真是讓人感慨萬分的錯(cuò)誤!我們這些與硬件打交道的程序員,為模數(shù)電生,為PCB死,為Debug奮斗一輩子,吃需求的虧,上大小寫的當(dāng),最后死在標(biāo)點(diǎn)上!!
5.?關(guān)于字母'O'和數(shù)字'0',以及字母'l'和數(shù)字'1'?,在嵌入式編程中很容易和寄存器打交道,一個(gè)CPU如果有兩個(gè)相同模塊時(shí),這些模塊寄存器,往往使用數(shù)字0和數(shù)字1來區(qū)分模塊0和模塊1,比如,NXP的ARM7 串口模塊的兩個(gè)接收緩沖寄存器分別為:U0RBR和U1RBR,要命的是在鍵盤上字母O和數(shù)字0相距的還那么近,你是否也有將上述寄存器寫成UORBR和UlRBR的經(jīng)歷,我是曾經(jīng)在這方面糾結(jié)過一次,好在編譯器能指出這個(gè)未定義的字符串。
6.?sizeof()? ? ? ??不知道有多少人和我曾經(jīng)一樣,將這個(gè)關(guān)鍵字認(rèn)為是一個(gè)庫函數(shù)。1.?int?i,j;??2. j=sizeof(i);?//對(duì)于這一句,當(dāng)初壓根沒把它往關(guān)鍵字上想,這家伙偽裝的實(shí)在夠好。?既然提到它,不如多說一下,sizeof在計(jì)算變量所占空間大小時(shí),括號(hào)可以省略,而計(jì)算類型大小時(shí),不能省略。什么意思呢?還是上面的變量聲明,可以寫成j=sizeof(i)也可以寫成j=sizeof i,因?yàn)檫@是計(jì)算變量所占空間大??;可以寫成j=sizeof(int),但不可以寫成j=sizeof int,因?yàn)檫@是計(jì)算數(shù)據(jù)類型大小。? ? ? ? ?總體來說,關(guān)鍵字sizeof的具有一定的變態(tài)基礎(chǔ)的,在我還是小白的時(shí)候,曾經(jīng)為下面的一道題傷過腦袋:
下面代碼里,假設(shè)在32位系統(tǒng)下,個(gè)sizeof計(jì)算的結(jié)果分別是多少?int?*p=NULL;? ? ? ? ? ? ?sizeof(p)的值是:? ? ? ? ? ? ?sizeof(*p)的值是:? ? ? ? ? ? ?int?a[100]? ? ? ? ? ? sizeof(a)的值是:? ? ? ? ? ? sizeof(a[100])的值是:? ? ? ? ? ? sizeof(