keil大常量計(jì)算問(wèn)題
但這一原則并不總能奏效,當(dāng)兩個(gè)常量做運(yùn)算時(shí)就可能導(dǎo)致溢出。如:
#define SYSCLK
#define SLIDER_REST_TIME
#define REST_DELAY
unsigned char i;
i = REST_DELAY;
在keil c51中運(yùn)行i為0xE1,即225,并不是期望的結(jié)果22118400 * 100 / (65536 * 1000) = 33.75,取整為33。原因分析如下:
宏替換后為:i = 22118400 * 100 / (65536 * 1000);,編譯器首先為22118400定義類型,因?yàn)?2118400不在int的表示范圍內(nèi),而在long int的范圍-2147483648~2147483647內(nèi),所以22118400按long int類型處理,在做乘積運(yùn)算時(shí)100被自動(dòng)按long int處理,22118400 * 100將按兩帶符號(hào)長(zhǎng)整型常量進(jìn)行運(yùn)算,運(yùn)算結(jié)果仍為帶符號(hào)長(zhǎng)整型,結(jié)果寫(xiě)成十六進(jìn)制是0x83D60000,其十進(jìn)制是-2083127296,顯然出現(xiàn)了溢出錯(cuò)誤。keil編譯器并沒(méi)有給出任何錯(cuò)誤或警告提示信息(VC++6.0還給出警告warning C4307: * : integral constant overflow),繼續(xù)進(jìn)行下一個(gè)運(yùn)算65536 * 1000,結(jié)果為帶符號(hào)長(zhǎng)整型,十六進(jìn)制為0x3E80000,十進(jìn)制為65536000,最后按兩長(zhǎng)整型除法計(jì)算-2083127296 / 65536000,結(jié)果為0xFFFFFFE1,由于i為字符類型,取0xFFFFFFE1的最低有效字節(jié)為0xE1賦值給i,i的最終值為0xE1。
解決這種溢出錯(cuò)誤的方法用C語(yǔ)言的一個(gè)術(shù)語(yǔ)就是“提升”(promotion),拿上例來(lái)說(shuō)就是將22118400指定為無(wú)符號(hào)長(zhǎng)整型,即:
#define SYSCLK
注:雖然只要將22118400、100、65536和1000四個(gè)常數(shù)中的一個(gè)指定為無(wú)符號(hào)長(zhǎng)整型即可得到正確的結(jié)果,但考慮到可讀性及規(guī)范性,應(yīng)選擇大整數(shù)指定其類型。
小結(jié):按C51編譯器的默認(rèn)類型整數(shù)常量運(yùn)算可能出現(xiàn)溢出錯(cuò)誤,對(duì)大整數(shù)應(yīng)指定其數(shù)據(jù)類型以避免出現(xiàn)可能的運(yùn)算錯(cuò)誤。
轉(zhuǎn)自:幽幽靈貓
uint16
time
實(shí)際運(yùn)行時(shí),60s定時(shí)總是感覺(jué)不到,也就是說(shuō)60s根本就沒(méi)定義成功。
理論上講,time
time
問(wèn)題解決。
但仍未完全明白其中道理,難道是編譯器的問(wèn)題,在此拋磚引玉,鄙人雖說(shuō)也有幾年程序經(jīng)驗(yàn),但哎,偏偏這么一個(gè)看似基礎(chǔ)性的東西卻不懂,
編程中無(wú)窮大常量的設(shè)定技巧2012年11月22日 13:08:05
轉(zhuǎn)自
如果問(wèn)題中各數(shù)據(jù)的范圍明確,那么無(wú)窮大的設(shè)定不是問(wèn)題,在不明確的情況下,很多程序員都取0x7fffffff作為無(wú)窮大,因?yàn)檫@是32-bit int的最大值。如果這個(gè)無(wú)窮大只用于一般的比較(比如求最小值時(shí)min變量的初值),那么0x7fffffff確實(shí)是一個(gè)完美的選擇,但是在更多的情況下,0x7fffffff并不是一個(gè)好的選擇。
- 很多時(shí)候我們并不只是單純拿無(wú)窮大來(lái)作比較,而是會(huì)運(yùn)算后再做比較,例如在大部分最短路徑算法中都會(huì)使用的松弛操作:
if (d[u]+w[u][v]我們知道如果u,v之間沒(méi)有邊,那么w[u][v]=INF,如果我們的INF取0x7fffffff,那么d[u]+w[u][v]會(huì)溢出而變成負(fù)數(shù),我們的松弛操作便出錯(cuò)了,更一般的說(shuō),0x7fffffff不能滿足“無(wú)窮大加一個(gè)有窮的數(shù)依然是無(wú)窮大”,它變成了一個(gè)很小的負(fù)數(shù)。 - 除了要滿足加上一個(gè)常數(shù)依然是無(wú)窮大之外,我們的常量還應(yīng)該滿足“無(wú)窮大加無(wú)窮大依然是無(wú)窮大”,至少兩個(gè)無(wú)窮大相加不應(yīng)該出現(xiàn)災(zāi)難性的錯(cuò)誤,這一點(diǎn)上0x7fffffff依然不能滿足我們。
所以我們需要一個(gè)更好的家伙來(lái)頂替0x7fffffff,最嚴(yán)謹(jǐn)?shù)霓k法當(dāng)然是對(duì)無(wú)窮大進(jìn)行特別處理而不是找一個(gè)很大很大的常量來(lái)代替它(或者說(shuō)模擬它),但是這樣會(huì)讓我們的編程過(guò)程變得很麻煩。在我讀過(guò)的代碼中,最精巧的無(wú)窮大常量取值是0x3f3f3f3f,我不知道是誰(shuí)最先開(kāi)始使用這個(gè)精妙的常量來(lái)做無(wú)窮大,不過(guò)我的確是從一位不認(rèn)識(shí)的ACMer(ID:Staginner)的博客上學(xué)到的,他/她的很多代碼中都使用了這個(gè)常量,于是我自己也嘗試了一下,發(fā)現(xiàn)非常好用,而當(dāng)我對(duì)這個(gè)常量做更深入的分析時(shí),就發(fā)現(xiàn)它真的是非常精巧了。
- 0x3f3f3f3f的十進(jìn)制是1061109567,也就是10^9級(jí)別的(和0x7fffffff一個(gè)數(shù)量級(jí)),而一般場(chǎng)合下的數(shù)據(jù)都是小于10^9的,所以它可以作為無(wú)窮大使用而不致出現(xiàn)數(shù)據(jù)大于無(wú)窮大的情形。
- 另一方面,由于一般的數(shù)據(jù)都不會(huì)大于10^9,所以當(dāng)我們把無(wú)窮大加上一個(gè)數(shù)據(jù)時(shí),它并不會(huì)溢出(這就滿足了“無(wú)窮大加一個(gè)有窮的數(shù)依然是無(wú)窮大”),事實(shí)上0x3f3f3f3f+0x3f3f3f3f=2122219134,這非常大但卻沒(méi)有超過(guò)32-bit int的表示范圍,所以0x3f3f3f3f還滿足了我們“無(wú)窮大加無(wú)窮大還是無(wú)窮大”的需求。
- 最后,0x3f3f3f3f還能給我們帶來(lái)一個(gè)意想不到的額外好處:如果我們想要將某個(gè)數(shù)組清零,我們通常會(huì)使用memset(a,0,sizeof(a))這樣的代碼來(lái)實(shí)現(xiàn)(方便而高效),但是當(dāng)我們想將某個(gè)數(shù)組全部賦值為無(wú)窮大時(shí)(例如解決圖論問(wèn)題時(shí)鄰接矩陣的初始化),就不能使用memset函數(shù)而得自己寫(xiě)循環(huán)了(寫(xiě)這些不重要的代碼真的很痛苦),我們知道這是因?yàn)閙emset是按字節(jié)操作的,它能夠?qū)?shù)組清零是因?yàn)?的每個(gè)字節(jié)都是0,現(xiàn)在好了,如果我們將無(wú)窮大設(shè)為0x3f3f3f3f,那么奇跡就發(fā)生了,0x3f3f3f3f的每個(gè)字節(jié)都是0x3f!所以要把一段內(nèi)存全部置為無(wú)窮大,我們只需要memset(a,0x3f,sizeof(a))。
所以在通常的場(chǎng)合下,0x3f3f3f3f真的是一個(gè)非常棒的選擇。
評(píng)論