在C/C++語言中，

在對(duì)源文件做預(yù)處理的時(shí)候，有兩條基本原則：

1、凡是以//開頭的為單行注釋

2、凡是以\結(jié)尾的代表此行尚未結(jié)束

于是預(yù)處理器在處理的時(shí)候會(huì)先按第二條規(guī)則，看每行的末尾的那個(gè)字符是不是”\”,是的

話，就下一行接到本行。

然后把所有以//開頭的注釋和/* */的塊注釋去掉。

但是存在一個(gè)問題，

對(duì)于big5中的漢字而言，其第一個(gè)字節(jié)的編碼范圍是0xA1 - 0xFE，第二個(gè)字節(jié)是0×40 -

0xFE。而’\'的ASCII碼是0×5c.這就意味這，凡是以big5編碼的文件，如果gcc沒有正確的

認(rèn)為它源文件的編碼是big5,那么就可能出現(xiàn)因?yàn)閱涡凶⑨屇┪彩菨h字，而把下行的代碼

吃掉的情況。這樣是很危險(xiǎn)的，但是gcc會(huì)給出一個(gè)警告：”warning: multi-line

comment In file”

這樣的問題在gbk中同樣存在。

將下面的代碼

—————————————————————————–

//你篭

int main(int argc,char* argv[]){

return 0;

}

—————————————————————————–

以gbk的方式保存，并采用gcc 3.4編譯。

無論是solaris 8還是freebsd 6.2,無論shell的locale的設(shè)置是zh_CN.GBK還是

zh_CN.UTF-8,所得到的錯(cuò)誤都是相同的

$ gcc -c testgbk.cpp

testgbk.cpp:5: error: expected unqualified-id before “return”

testgbk.cpp:6: error: expected declaration before ‘}’ token

g++ 3.3下顯示：

testgbk.cpp:3: error: parse error before `return’

原因很簡(jiǎn)單，我把“好”字的GBK編碼的后半個(gè)字節(jié)改成了’\'的編碼，從而得到了”篭”字。

gcc發(fā)現(xiàn)’\'后面接著的就是’\n’,故而把下一行”int main(int argc,char* argv[]){”也

當(dāng)做注釋一并刪除掉了。

按gcc 3.4的man頁，gcc會(huì)根據(jù)shell的locale設(shè)置來猜測(cè)源文件的編碼格式，否則它會(huì)把

其當(dāng)作utf-8來處理。但是據(jù)我在Freebsd和solaris系統(tǒng)中觀察，gcc 3.4并沒有根據(jù)環(huán)境

變量來猜測(cè)源文件的編碼。

一個(gè)不錯(cuò)的解決方案是，強(qiáng)行給gcc添加-finput-charset=big5這樣的參數(shù)，來解決此問

題。類似的還有-fexec-charset，-fwide-exec-charset用于指定執(zhí)行環(huán)境的編碼。但是

不幸的是，gcc內(nèi)部的處理都是基于utf-8的,且其轉(zhuǎn)換工作一般是靠系統(tǒng)的iconv轉(zhuǎn)碼庫來

完成的。 所以系統(tǒng)庫必須提供 GBK UTF-8 、BIG5 UTF-8 的編碼.

例如，我在Freebsd 6.2下使用這樣的參數(shù)編譯一個(gè)測(cè)試文件：

$ gcc -c testbig5.cpp -finput-charset=big5 -fexec-charset=big5 -fwide-exec-charset=big5

所得到的輸出是：

cc1plus: no iconv implementation, cannot convert from big5 to UTF-8

cc1plus: no iconv implementation, cannot convert from UTF-8 to big5

cc1plus: no iconv implementation, cannot convert from UTF-8 to big5

所以這種方案的缺點(diǎn)是

1、缺乏通用性，缺乏可移植性。

Freebsd的內(nèi)核中的轉(zhuǎn)碼是靠查一個(gè)16位的表，所以無法處理utf-8中的漢字(因?yàn)闈h字是3

字節(jié)),而直到最新的，要到08才能發(fā)布的Freebsd 7.x,此問題也依然沒有被解決。

而Solaris最初的代碼是基于BSD的。它所提供的iconv轉(zhuǎn)碼功能也非常差。

2、添加了很多額外的轉(zhuǎn)碼操作。

目前，utf-8(unicode)尚未完全容納GBK、big5的全部字符。很多字符是轉(zhuǎn)換不過去的。

另一個(gè)折衷的方案是：保證每行注釋都以句號(hào)或者空格結(jié)尾。

缺點(diǎn)是，需要檢查并改動(dòng)很多文件。

且，特殊漢字依然有可能出現(xiàn)在源文件的常量字符串中。問題依舊。

例如

const char* s=”你篭”;

寫成這樣的怪樣子就可以編譯了：

const char* s=”你篭”";

較好的解決方案是源文件都以UTF-8格式編碼。這樣可以最大限度的減少轉(zhuǎn)碼次數(shù)。

最徹底的解決方案是引入gettext，不在源文件中存儲(chǔ)漢字的常量字符串。改用單獨(dú)的文件

存儲(chǔ)。目前包括很多php論壇、blog都已采用這種方案。但是這樣做本來是為了支持英、

法、漢多語言，解決翻譯的問題。如果單為了簡(jiǎn)、繁的問題就這么做，代價(jià)太大。

總結(jié)

以上是生活随笔為你收集整理的c语言的单行注释范围,c语言中的注释，multi-line comment的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。