1.關于+=以及-=
這是兩個運算符,但你否有過這種經歷:
[cpp]view plaincopy
inttemp;
chari
for(i=0;i
{
...
temp=+2;//這里本意是每次循環,temp都自增2,但是卻將'+='寫成了'=+',按照這種寫法,每次循環都為temp賦值正數2,與本意相差甚遠
}
2. 關于意想不到的死循環
[cpp]view plaincopy
unsignedchari;
for(i=0;i<256;i++)??
{
//something
}
當我們用上述代碼想實現一個小循環時,結果卻事與愿違,這其實是死循環的另一種寫法,因為無符號變量i最大只有255,要命的是,編譯器并不會指出這個錯誤。
與之相類似的代碼是:
[cpp]view plaincopy
unsignedchari;
for(i=10;i>=0;i--)
{
//something
}
這也是一個死循環,你看出什么原因了嗎?無論i如何減,i都是大于等于0的。
這就告訴我們對于每個變量類型的取值范圍要由清醒的認識。值得注意的是相同的變量類型對于不同的CPU構架和不同的編譯器會有不同的結果。比如int類型在大多數16位CPU構架中占用兩個字節,但在32位CPU中卻往往占用4個字節;char類型在絕大多數編譯器中都是有符號數,但在keilMDK中卻是無符號數,若是要在keilMDK下定義有符號char類型變量,必須用signed顯式聲明。我曾讀過一本書,其中有一句話:“signed關鍵字也是很寬宏大量,你也可以完全當它不存在,在缺省狀態下,編譯器默認數據位signed類型”,這句話便是有異議的,我們應該對自己所用的CPU構架以及編譯器熟練掌握。
3. 關于'='和'=='
[cpp]view plaincopy
if(Value=0x01)
{
//something
}
當我們判斷一個變量是否等于0x01時,你是否也寫過類似上面的代碼?C語言的創造者認為賦值運算符"="出現的概率要遠遠大于等于運算符"==",因此,我們正常邏輯中的"等于"符號(=)在C語言中成了賦值運算符,而C語言的"等于"運算符卻被兩個等于號(==)所代替。我之所以對這個事件耿耿于懷是因為我在大二的時候參加的C++二級上機考試,當我感覺很輕松的做完最后一道題后,卻發現運算的結果卻與邏輯相悖,經過調試發現,有一個條件一直為真,我檢查了很多遍才發現出問題的邏輯將等于運算符寫成了賦值運算符。在if語句中給變量賦一個非零值,也難怪這個邏輯總是為真。
編譯器同樣不對這個問題做出指導性建議,值得一提的是,如果你在Keil的if語句中使用了賦值運算符,編譯器會給出警告。
避免這個問題的一個很好的辦法是使用良好編程習慣,比如上面的代碼可寫為:
[cpp]view plaincopy
if(0x01==Value)
{
//something
}
將常量值放到變量的前面,即使將等于運算符寫成賦值運算符,編譯器也能產生一個語法錯誤,因為將一個變量賦值給一個常量是非法的。
4.error:#7:unrecognizedtoken
我在剛使用C語言以及Keil編譯器時,對于這個編譯器錯誤,有很深的印象。出現這個編譯錯誤的典型代表是在敲代碼的時候輸入了中文標點??!
真是讓人感慨萬分的錯誤!我們這些與硬件打交道的程序員,為模數電生,為PCB死,為Debug奮斗一輩子,吃需求的虧,上大小寫的當,最后死在標點上??!
5.關于字母'O'和數字'0',以及字母'l'和數字'1',在嵌入式編程中很容易和寄存器打交道,一個CPU如果有兩個相同模塊時,這些模塊寄存器,往往使用數字0和數字1來區分模塊0和模塊1,比如,NXP的ARM7串口模塊的兩個接收緩沖寄存器分別為:U0RBR和U1RBR,要命的是在鍵盤上字母O和數字0相距的還那么近,你是否也有將上述寄存器寫成UORBR和UlRBR的經歷,我是曾經在這方面糾結過一次,好在編譯器能指出這個未定義的字符串。
6.sizeof()
不知道有多少人和我曾經一樣,將這個關鍵字認為是一個庫函數。
[cpp]view plaincopy
inti,j;
j=sizeof(i);//對于這一句,當初壓根沒把它往關鍵字上想,這家伙偽裝的實在夠好。
既然提到它,不如多說一下,sizeof在計算變量所占空間大小時,括號可以省略,而計算類型大小時,不能省略。什么意思呢?還是上面的變量聲明,可以寫成j=sizeof(i)也可以寫成j=sizeofi,因為這是計算變量所占空間大小;可以寫成j=sizeof(int),但不可以寫成j=sizeofint,因為這是計算數據類型大小。
總體來說,關鍵字sizeof的具有一定的變態基礎的,在我還是小白的時候,曾經為下面的一道題傷過腦袋:
下面代碼里,假設在32位系統下,個sizeof計算的結果分別是多少?
int*p=NULL;
sizeof(p)的值是:
sizeof(*p)的值是:
inta[100]
sizeof(a)的值是:
sizeof(a[100])的值是:
sizeof(&a)的值是:
sizeof(&a[0])的值是:
intb[100];
voidfun(intb[100])
{
sizeof(b);
}
sizeof(b)的值為:
7 關于數組越界
[cpp]view plaincopy
inta[30];
for(i=30;i>0;i--)
{
a[i]=something;
}
這是個典型的數組越界例子,最近我同事的一個程序中便出現了。不知道有多少同學遇到或將要遇到數組越界問題,即便你定義了30個數組a[30],你也不可以為a[30]賦值,因為下標為30的元素已經越界了。所以說數組下標定義的很奇特,它是從0開始的。但當我們還是新手的時候,最容易忽視這一點。幸好現在的有些編譯器會對這個越界產生警告信息。
8. 關于宏
[cpp]view plaincopy
#defineMAX_TAST4;
這個錯誤編譯器會指出的,即便這樣,相信很多同學在最初的時候也不會在第一時間發現這句代碼的最后多了一個分號。這個分號會導致一些編譯器報錯,因為宏定義的結尾并不需要分號。
同樣與define有關的是這樣一句:#define"config.h",我便吃過類似暗虧,在編譯器的提示之下,看了幾遍才發現頭文件包含應該是#include"config.h"。
既然提到#define,還是說說它需要注意的幾個點,也是經常在資料上被提及的。
a.使用#define時,括號一定要足夠。比如定義一個宏函數,求x的平方:
[cpp]view plaincopy
#defineSQR(x)x*x..............1
或者這樣寫:
[cpp]view plaincopy
#defineSQR(x)(x)*(x)...............2
上面兩種都是有風險的,對于第一種定義,SQR(10+1)就會得到和我們的設想不一致的結果;第二種SQR(5*3)*SQR(5*3)也會得到和我們設想不一致的結果,因此更安全的定義方法是:
[cpp]view plaincopy
#defineSQR(x)((x)*(x))
b.使用#define的時候,,意空格的使用。比如下面的例子:
[cpp]view plaincopy
#defineSQR(x)((x)*(x))
這已經不是SQR(x)函數了,編譯器會把認為定義了一個宏SQR,代表(x)((x)*(x)),因為SQR與(x)之間有空格。這點需要注意。
c.使用'#'在字符串中包含宏參數。比如下面的例子:
[cpp]view plaincopy
#defineSQR(x)printf("Thesquareofxis%d.\n",((x)*(x))")
[cpp]view plaincopy
如果這樣使用宏:
[cpp]view plaincopy
SQR(8)
則輸出為:
Thesquareofxis64.
這個時候引號中的x被當做字符串來處理了,而不是一個可以被宏參數替換的符號.如果你想在字符中的x也被宏參數替換,可以這么來定義宏:
[cpp]view plaincopy
#defineSQR(x)printf("Thesquareof"#x"is%d.\n",((x)*(x))")
這樣得到的結果為:
Thesquareof8is64.
上面的這些例子,恐怕是網上隨處可見的,但真的會這么用卻有待考證。下面給出一個我自己遇到的不加括號產生錯誤的例子。在嵌入式編程中,遇到讀取IO端口某一位的電平狀態的場合是在平常不過的了,比如在NXP的ARM7中,讀取端口P0.11的電平狀態并判斷是否為高電平,代碼如下:
[cpp]view plaincopy
#defineREADSDAIO0PIN&(1<<11)????????????//定義宏,讀IO口p0.11的端口狀態,但并未使用足夠多的括號??
//判斷p0.11端口是否為高電平,使用下述語句就是錯誤的:
if(READSDA==(1<<11))??
{
//是高電平,處理高電平的問題
}
編譯器在編譯后將宏帶入,原if語句變為:
[cpp]view plaincopy
if(IO0PIN&(1<<11)?==(1<<11))??
{
//是高電平,處理高電平的問題
}
這樣的話,運算符'=='的優先級是大于'&'的,從而IO0PIN&(1<<11)?==(1<<11))語句等效為IO0PIN&0x00000001,相當于判斷P0.1是否為高電平,與原意相差甚遠.
9.數組和指針
在32位系統下,
定義一個數組:
[cpp]view plaincopy
inta[10]={1,2,3,4,5,6,7,8,9,0};
定義一個指針:
[cpp]view plaincopy
int*p;
那么,a、a[0]、&a、&a[0]各表示什么意思?
那么,sizeof(a)、sizeof(a[0])、sizeof(&a)、sizeof(&a[0])的值各是什么?
如果,對指針p賦值:
p=a;
并且通過編譯器仿真,得知現在p等于a等于0x00000200,
那么,a+1=?
&a+1=?
p+1=?
p[2]=?
*(p+2)=?
*(a+2)=?
再如果
[cpp]view plaincopy
int*ptr=(int*)(&a+1);
那,*(ptr-1)=?
世上最曖昧、最糾纏不清的,莫過于數組名和指針。這一方面源于大學的教材并沒有重視這一塊,也源于教學時硬生生的將C語言和硬件分開。一方面,教材和教這一門的老師在開始時便向我們灌輸了“數組名和指針很像,可以等同”的思想;另一方面,在學C語言的時候,并沒有系統的學過計算機硬件(尋址、存儲、匯編),C語言是一個很接近硬件的高級語言,如果沒有處理器(包括單片機等微處理器)的基礎知識,會導致非常多的同學怎么都理解不透C語言的指針和數組。
當我們定義一個數組inta[10]時,編譯器會分配一塊內存,這塊內存的名字命名為a,這個a只是一個名字,只是方便編譯器和編程者使用,編譯器并不為這個名字分配空間來存儲它。我們可以用a[0]、a[1]來訪問數組內的元素。a作為右值(位于等號的右邊)時,表示的是數組第一個元素的地址(意義與&a[0]一樣,但&a[0]是一個指針變量,編譯器會為他分配空間,a卻不一樣,編譯器并不為它分配什么空間),而并非數組首地址,&a才表示數組的首地址。
所以,第一個問題,a是這個數組所在的內存的名字,當它為右值時,表示數組首元素的地址,a[0]是數組的第一個元素,其值等于1,&a是整個數組的首地址,它是一個指針;&a[0]是數組首元素的地址,它的值和a做右值時一樣,但意義不同,因為&a[0]是一個指針,編譯器要為它分配存儲空間,但a卻不會被分配存儲空間,a也不是指針型變量。
明白了上面那些,關于sizeof的計算也就不會困難了:
sizeof(a)=4*10=40,因為a代表的是整塊數組內存;
sizeof(a[0])=4,這相當于計算int的大小,在32位系統下,int占4個字節。
sizeof(&a)和sizeof(&a[0])都是計算指針變量的大小,在32位系統下,指針變量占4個字節。
對于最后一個問題,涉及到指針的加減。
指針的加減中有一個重要的原則就是它的加減跟我們普通意義上的加減不是一個概念,它是按指針所指類型的內存大小來進行加減的。當我還是一個新手的時候,對于p++、p+1這類指針運算的含義超出了我的意料之外,在上例中,若是p=0x00000200,那么p++運算之后的p值應該為0x00000204。有多少同學,曾經把它計算成0x00000201!
數組名a在做計算的時候表示數組首元素的地址,這時候a等于0x00000200,所以a+1等于0x00000200+4=0x00000204,因為一個int型在32位系統下占用4個字節。&a是整個數組的首地址,&a+1=0x00000200+4*10=0x00000228。
其它的也都比較好理解,p+1=0x00000200+04=0x00000204、p[2]=3、*(p+2)=3、*(ptr-1)=0.
10.3/(-3)=?
3%(-2)=?
(-3)%2=?
拋開它是否有實際的意義,這個看似簡單的語句,不知道有多少同學不確定結果到底是什么。
其實大多數的編譯器遵循這樣一個規定:余數與被除數的正負號相同,被除數等于結果乘以除數加上余數。所以,以上的三個結果分別為-1、1、-1。
11.指針數組與數組指針
有一段時間,我怎么都不能區分指針數組和數組指針,就像下面的聲明:
[cpp]view plaincopy
int*p1[10];
int(*p2)[10];
首先,要來解釋一下什么是指針數組,什么是數組指針:指針數組首先是一個數組,它的成員都是指針型變量;數組指針首先是一個指針,這個指針指向一個數組(它的值和數組名表示的值一樣,只是數組指針是一個變量,編譯器要為它分配存儲空間,但數組名類似于一個常亮,是編譯器在編譯階段就確定好的一個值,編譯器不會為它分配存儲空間)。
對于p1,由于中括號的優先級(關于優先級,后面會專門提起)是大于*的,所以p1首先與'[]'相結合,構成一個數組,在這個數組之前又有一個'*'運算符,說明這是定義一個指針數組(int*a:定義一個指針a,這里可以將p1[10]替換成a,就不難理解了),數組的元素都是指向int型的指針。
對于p2,'()'雖然與'[]'為同一優先級,但卻是表達式結合方向從左到右結合的,所以編譯器會先處理(*p2),這是典型的定義一個指針,只不過這個指針指向一個包含10個int型數據的內存塊。為了加強理解,這里給出兩個相同原理的函數聲明:
void*p1(void);----------------------聲明1,定義一個返回值是void類型指針的函數p1
void(*p2)(void);-----------------------聲明2,定義一個函數指針,該函數不返回任何值
有了上面的鋪墊,現在定義一個高級C語言編程技巧中常用的函數指針數組應該很容易了吧!首先這是一個數組,數組的元素是指向一個函數的指針,以定義一個參數為空,返回值為int類型的函數指針數組p1為例:
[cpp]view plaincopy
int(*p1[5])(void);
分析如下:
定義一個返回值為int類型的函數指針p1應該是:
[cpp]view plaincopy
int(*p1)(void);
那么將這類指針放到一個數組中不正是我們需要的定義嗎,套用指針數組的定義方法,返回值為int類型函數指針數組定義為:int(*p1[5])(void);
12.運算符的優先級
C語言有32個關鍵字卻有44個運算符!運算符之間有固定的優先級,雖然它們可以分成15類優先級,但如果讓一個程序員完全記住這些運算符之間的優先級關系,怕是老手也是不容易的吧。如果你的程序只是語法錯誤,這類錯誤是最容易解決的,編譯器就會幫你檢測出來;如果是你自己的邏輯出現錯誤,那么根據運行結果仔細檢查一下代碼可能也不難發現;但若是你的邏輯正確卻記錯了運算符的優先級關系,導致程序運行結果和你設想的不同,這種錯誤就很難查出了,因為在你的潛意識里,已經把這種錯誤點當成理所當然不用關注的。
請看下面一句代碼代表什么意思:
[cpp]view plaincopy
*string++;
由于*和++但是單目運算符,優先級相同,但結合方向卻是自右向左,那么*string++應該就是*(string++),取出當前字符后將指針后移。不知道有沒有人把它認為是(*string)++,即取指針string所指向的對象,然后將該對象增1.
我曾經在代碼中不止一次的出現過因為優先級問題而導致的程序邏輯錯誤,那個時候我并沒有完整的記過優先級,二十使用了一種“偷巧”的方法:只是簡單記住前幾級優先級,其它自己沒把握的一律使用括號。這種方法我現在是不推薦的,一是因為大量的括號影響代碼閱讀和程序的簡潔,二是總有時候我們稍微一松懈,就忘記了加括號,而后一種情況,正是很多人可能會遇到的。比如下面一句代碼,無符號8位變量ucTimeValue中存放十進制編碼的數據23,我想將十進制編碼轉成16進制編碼,代碼為:
[cpp]view plaincopy
temp8=(ucTimeValue>>4)*10+ucTimeValue&0x0F;//十進制轉化為16進制,但忽略了運算符'+'的優先級是大于運算符'&'的
像這類代碼編譯肯定可以通過,但運行的結果卻出乎我的意料,而且由于我先入為主的錯誤思想,要在一大段代碼中發現這個錯誤著實要花費一番功夫。
再例如,如果我想判斷一個寄存器的某一位是否為零,假如是判斷寄存器IO0SET的bit17是否為零,但代碼卻寫成了這樣:
[cpp]view plaincopy
if(IO0SET&(1<<17)==0)???
這樣寫其實是得不到正確的結果的,因為我忽略了"=="的優先級是大于"&"的.按照上面的代碼分析:因為"=="的優先級大于"&",所以程序先判斷(1<<17)是否等于0?發現這是不相等的,所以(1<<17)==0表達式的值為假,即為0,0與(&)上任何一個數都是0,所以IO0SET&(1<<17))==0整個表達式的值永遠為0,這與原意相差甚遠。?
按照原意,應該這樣寫:
[cpp]view plaincopy
if((IO0SET&(1<<17)))==0)??
其實,運算符的優先級是有一定的規律可循的,下面給出優先級口訣(注:口訣來源于互聯網)
優先級口訣
括號成員第一; 括號運算符[]()成員運算符.->
全體單目第二; 所有的單目運算符比如++--+(正)-(負)指針運算*&
乘除余三,加減四; 這個"余"是指取余運算即%
移位五,關系六; 移位運算符:<>>,關系:>>=<=?等
等于(與)不等排第七; 即==!=
位與異或和位或; 這幾個都是位運算:位與(&)異或(^)位或(|)
"三分天下"八九十;
邏輯或跟與; 邏輯運算符:||和&&
十二和十一; 注意順序:優先級(||)底于優先級(&&)
條件高于賦值, 三目運算符優先級排到13位只比賦值運算符和","高
逗號運算級最低! 逗號運算符優先級最低
-
C語言
+關注
關注
180文章
7599瀏覽量
136213 -
編譯器
+關注
關注
1文章
1618瀏覽量
49052
原文標題:曾讓我哭笑不得抓狂的C語言
文章出處:【微信號:wujianying_danpianji,微信公眾號:單片機精講吳鑒鷹】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論