C語言 程式設計小技巧(二)

2021-09-26 19:53:27 字數 2151 閱讀 5133

引數的書寫要完整,不要貪圖省事只寫引數的型別而省略引數名字。如果函式沒有引數,則用void填充。例如:

voidsetvalue

(intwidth,intheight)

;// 良好的風格

voidsetvalue

(int

,int);

// 不良的風格

floatgetvalue

(void);

// 良好的風格

floatgetvalue()

;// 不良的風格

例如編寫字串拷貝函式stringcopy,它有兩個引數。如果把引數名字起為str1和str2,例如:

void

stringcopy

(char

*str1,

char

*str2)

;

那麼我們很難搞清楚究竟是把str1拷貝到str2中,還是剛好倒過來。

可以把引數名字起得更有意義,如叫strsourcestrdestination。這樣從名字上就可以看出應該把strsource拷貝到strdestination。

還有乙個問題,這兩個引數那乙個該在前那乙個該在後?引數的順序要遵循程式設計師的習慣。一般地,應將目的引數放在前面,源引數放在後面:

void

stringcopy

(char

*strdestination,

char

*strsource)

;

如果引數是指標,且僅作輸入用,則應在型別前加const,以防止該指標在函式體內被意外修改。

例如:

void

stringcopy

(char

*strdestination,constchar*strsource)

;

違反這條規則的典型代表是c標準庫函式getchar。例如:

charc;

c=getchar()

;if(c==

eof)

按照getchar名字的意思,將變數c宣告為char型別是很自然的事情。但不幸的是getchar的確不是char型別,而是int型別,其原型如下:

int

getchar

(void

);

由於c是char型別,取值範圍是[-128,127],如果巨集eof的值在char的取值範圍之外,那麼if語句將總是失敗,這種「危險」人們一般**料得到!導致本例錯誤的責任並不在使用者,是函式getchar誤導了使用者。

正常值用輸出引數獲得,而錯誤標誌用return語句返回。

回顧上例,c標準庫函式的設計者為什麼要將getchar宣告為令人迷糊的int型別呢?

在正常情況下,getchar的確返回單個字元。但如果getchar碰到檔案結束標誌或發生讀錯誤,它必須返回乙個標誌eof。為了區別於正常的字元,只好將eof定義為負數(通常為負1)。因此函式getchar就成了int型別。

我們在實際工作中,經常會碰到上述令人為難的問題。為了避免出現誤解,我們應該將正常值和錯誤標誌分開。即:正常值用輸出引數獲得,而錯誤標誌用return語句返回。

函式getchar可以改寫成bool getchar(char*c);

有時候函式原本不需要返回值,但為了增加靈活性如支援鏈式表達,可以附加返回值。例如字串拷貝函式strcpy的原型:

char

*strcpy

(char

*strdest,const

char

*strsrc)

;

strcpy函式將strsrc拷貝至輸出引數strdest中,同時函式的返回值又是strdest。這樣做並非多此一舉,可以獲得如下靈活性:

char str[20]

;int length=

strlen

(strcpy

(str,「helloworld」)

);

C 程式設計小技巧

1.乙個應用程式只能被使用者開啟一次 process mobj pro process.getcurrentprocess process mobj prolist process.getprocessesbyname mobj pro.processname if mobj prolist.len...

C 程式設計小技巧

定義常量並賦乙個很大的值 方法一 int minarea 1 30 minarea 1073741824,表示將乙個運算物件的各二進位制位全部左移若干位 左邊的二進位制位丟棄,右邊補0 例 a a 2 將a的二進位制位左移2位,右補0,左移1位後a a 2 若左移時捨棄的高位不包含1,則每左移一位,...

C 程式設計小技巧

1 使用常量引用形式,將map作為形參傳遞時的問題 void test const unordered map um 上述 將不能通過編譯。原因 map的運算子會在索引項不存在的時候自動建立乙個物件,而常量不能改變。解決辦法 使用迭代器替換即可,如下例所示。void test const unord...