青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

陳碩的Blog

C++ 工程實踐(1):慎用匿名 namespace

匿名 namespace (anonymous namespace 或稱 unnamed namespace) 是 C++ 的一項非常有用的功能,其主要目的是讓該 namespace 中的成員(變量或函數)具有獨一無二的全局名稱,避免名字碰撞 (name collisions)。一般在編寫 .cpp 文件時,如果需要寫一些小的 helper 函數,我們常常會放到匿名 namespace 里。muduo 0.1.7 中的 muduo/base/Date.ccmuduo/base/Thread.cc 等處就用到了匿名 namespace。

我最近在工作中遇到并重新思考了這一問題,發現匿名 namespace 并不是多多益善。

C 語言的 static 關鍵字的兩種用法

C 語言的 static 關鍵字有兩種用途:

1. 用于函數內部修飾變量,即函數內的靜態變量。這種變量的生存期長于該函數,使得函數具有一定的“狀態”。使用靜態變量的函數一般是不可重入的,也不是線程安全的。

2. 用在文件級別(函數體之外),修飾變量或函數,表示該變量或函數只在本文件可見,其他文件看不到也訪問不到該變量或函數。專業的說法叫“具有 internal linkage”(簡言之:不暴露給別的 translation unit)。

C 語言的這兩種用法很明確,一般也不容易混淆。

C++ 語言的 static 關鍵字的四種用法

由于 C++ 引入了 class,在保持與 C 語言兼容的同時,static 關鍵字又有了兩種新用法:

3. 用于修飾 class 的數據成員,即所謂“靜態成員”。這種數據成員的生存期大于 class 的對象(實體 instance)。靜態數據成員是每個 class 有一份,普通數據成員是每個 instance 有一份,因此也分別叫做 class variable 和 instance variable。

4. 用于修飾 class 的成員函數,即所謂“靜態成員函數”。這種成員函數只能訪問 class variable 和其他靜態程序函數,不能訪問 instance variable 或 instance method。

當然,這幾種用法可以相互組合,比如 C++ 的成員函數(無論 static 還是 instance)都可以有其局部的靜態變量(上面的用法 1)。對于 class template 和 function template,其中的 static 對象的真正個數跟 template instantiation (模板具現化)有關,相信學過 C++ 模板的人不會陌生。

可見在 C++ 里 static 被 overload 了多次。匿名 namespace 的引入是為了減輕 static 的負擔,它替換了 static 的第 2 種用途。也就是說,在 C++ 里不必使用文件級的 static 關鍵字,我們可以用匿名 namespace 達到相同的效果。(其實嚴格地說,linkage 或許稍有不同,這里不展開討論了。)

匿名 namespace 的不利之處

在工程實踐中,匿名 namespace 有兩大不利之處:

  1. 其中的函數難以設斷點,如果你像我一樣使用的是 gdb 這樣的文本模式 debugger。
  2. 使用某些版本的 g++ 時,同一個文件每次編譯出來的二進制文件會變化,這讓某些 build tool 失靈。

考慮下面這段簡短的代碼 (anon.cc):

   1: namespace
   2: {
   3:   void foo()
   4:   {
   5:   }
   6: }
   7:  
   8: int main()
   9: {
  10:   foo();
  11: }

對于問題 1:

gdb 的<tab>鍵自動補全功能能幫我們設定斷點,不是什么大問題。前提是你知道那個"(anonymous namespace)::foo()"正是你想要的函數。

$ gdb ./a.out
GNU gdb (GDB) 7.0.1-debian

(gdb) b '<tab>
(anonymous namespace)         __data_start                  _end
(anonymous namespace)::foo()  __do_global_ctors_aux         _fini
_DYNAMIC                      __do_global_dtors_aux         _init
_GLOBAL_OFFSET_TABLE_         __dso_handle                  _start
_IO_stdin_used                __gxx_personality_v0          anon.cc
__CTOR_END__                  __gxx_personality_v0@plt      call_gmon_start
__CTOR_LIST__                 __init_array_end              completed.6341
__DTOR_END__                  __init_array_start            data_start
__DTOR_LIST__                 __libc_csu_fini               dtor_idx.6343
__FRAME_END__                 __libc_csu_init               foo
__JCR_END__                   __libc_start_main             frame_dummy
__JCR_LIST__                  __libc_start_main@plt         int
__bss_start                   _edata                        main

(gdb) b '(<tab>
anonymous namespace)         anonymous namespace)::foo()

(gdb) b '(anonymous namespace)::foo()'
Breakpoint 1 at 0x400588: file anon.cc, line 4.

麻煩的是,如果兩個文件 anon.cc 和 anonlib.cc 都定義了匿名空間中的 foo() 函數(這不會沖突),那么 gdb 無法區分這兩個函數,你只能給其中一個設斷點。或者你使用 文件名:行號 的方式來分別設斷點。(從技術上,匿名 namespace 中的函數是 weak text,鏈接的時候如果發生符號重名,linker 不會報錯。)

從根本上解決的辦法是使用普通具名 namespace,如果怕重名,可以把源文件名(必要時加上路徑)作為 namespace 名字的一部分。

對于問題 2:

把它編譯兩次,分別生成 a.out 和 b.out:

$ g++ -g -o a.out anon.cc

$ g++ -g -o b.out anon.cc

$ md5sum a.out b.out
0f7a9cc15af7ab1e57af17ba16afcd70  a.out
8f22fc2bbfc27beb922aefa97d174e3b  b.out

$ g++ --version
g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

$ diff -u <(nm a.out) <(nm b.out)
--- /dev/fd/63  2011-02-15 22:27:58.960754999 +0800
+++ /dev/fd/62  2011-02-15 22:27:58.960754999 +0800
@@ -2,7 +2,7 @@
0000000000600940 d _GLOBAL_OFFSET_TABLE_
0000000000400634 R _IO_stdin_used
                  w _Jv_RegisterClasses
-0000000000400538 t _ZN36_GLOBAL__N_anon.cc_00000000_E2CEEB513fooEv
+0000000000400538 t _ZN36_GLOBAL__N_anon.cc_00000000_CB51498D3fooEv
0000000000600748 d __CTOR_END__
0000000000600740 d __CTOR_LIST__
0000000000600758 d __DTOR_END__

由上可見,g++ 4.2.4 會隨機地給匿名 namespace 生成一個惟一的名字(foo() 函數的 mangled name 中的 E2CEEB51 和 CB51498D 是隨機的),以保證名字不沖突。也就是說,同樣的源文件,兩次編譯得到的二進制文件內容不相同,這有時候會造成問題。比如說拿到一個會發生 core dump 的二進制可執行文件,無法確定它是由哪個 revision 的代碼編譯出來的。畢竟編譯結果不可復現,具有一定的隨機性。

這可以用 gcc 的 -frandom-seed 參數解決,具體見文檔。

這個現象在 gcc 4.2.4 中存在(之前的版本估計類似),在 gcc 4.4.5 中不存在。

替代辦法

如果前面的“不利之處”給你帶來困擾,解決辦法也很簡單,就是使用普通具名 namespace。當然,要起一個好的名字,比如 boost 里就常常用 boost::detail 來放那些“不應該暴露給客戶,但又不得不放到頭文件里”的函數或 class。

 

總而言之,匿名 namespace 沒什么大問題,使用它也不是什么過錯。萬一它礙事了,可以用普通具名 namespace 替代之。

posted on 2011-02-15 22:55 陳碩 閱讀(6828) 評論(3)  編輯 收藏 引用

評論

# re: C++ 工程實踐(1):慎用匿名 namespace 2011-02-16 09:31 zuhd

喜歡樓主這種寫作風格,深入淺出,感覺像是以前高中時做證明題一樣,很清晰  回復  更多評論   

# re: C++ 工程實踐(1):慎用匿名 namespace 2011-02-17 13:20 淘寶皇冠店

很好12659965  回復  更多評論   

# re: C++ 工程實踐(1):慎用匿名 namespace 2011-02-18 10:48 zwp

首先,匿名空間最大的好處是不用擔心名字沖突。如果,你能保證現有的代碼或者以后的代碼都不會使用你的具名空間的話,當然可以使用具名空間。而這也正是使用匿名空間的理由。

具名空間是一種封閉、限制和警戒,意味著可能的沖突。
匿名空間則像一個開放的獨立的組織,一定程度上代表著可擴展。  回復  更多評論   


只有注冊用戶登錄后才能發表評論。
網站導航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


<2011年2月>
303112345
6789101112
13141516171819
20212223242526
272812345
6789101112

導航

統計

常用鏈接

隨筆分類

隨筆檔案

相冊

搜索

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            国产日韩av在线播放| 99在线精品观看| 蜜臀av国产精品久久久久| 一本色道综合亚洲| 国产精品99久久久久久有的能看| 亚洲国产精品福利| 小黄鸭精品aⅴ导航网站入口| 妖精成人www高清在线观看| 亚洲人成艺术| 亚洲一品av免费观看| 亚洲一级二级| 久久久久久久久久久久久女国产乱| 亚洲欧美综合一区| 亚洲国产电影| 性色一区二区| 久久婷婷丁香| 亚洲少妇诱惑| 久久久久久久综合色一本| 欧美激情中文字幕一区二区| 国产精品麻豆va在线播放| 在线国产日韩| 久久人人97超碰人人澡爱香蕉 | 久久视频一区二区| 国产精品久久久久久福利一牛影视| 精品二区视频| 欧美一级精品大片| 亚洲一区二区影院| 国产精品成人一区二区三区夜夜夜 | 久久一区中文字幕| 国产免费成人av| 日韩视频中文| 亚洲激情第一页| 欧美精选午夜久久久乱码6080| 亚洲精品视频一区二区三区| 久久久久久久波多野高潮日日| 亚洲综合清纯丝袜自拍| 国产精品久久国产愉拍| 亚洲欧美在线高清| 久久成人免费日本黄色| 国模私拍视频一区| 久久综合亚洲社区| 久久一区二区三区av| 99国产精品久久久| 亚洲天堂av高清| 国产亚洲一级| 亚洲日韩欧美视频一区| 91久久精品一区二区三区| 欧美日韩国产区| 久久久久久综合网天天| 欧美韩日精品| 久久视频精品在线| 欧美久久婷婷综合色| 久久精品视频播放| 免费观看成人www动漫视频| 午夜久久美女| 欧美精品在线免费| 欧美成人免费小视频| 国产精品综合| 99riav久久精品riav| 在线日韩视频| 久久久一区二区| 久久久久综合网| 国产亚洲网站| 久久一二三区| 欧美电影打屁股sp| 亚洲欧洲日本专区| 亚洲另类自拍| 欧美肉体xxxx裸体137大胆| 亚洲国产小视频| 99在线热播精品免费| 欧美成人国产va精品日本一级| 美女黄网久久| 亚洲精品久久久久久久久久久久| 久久精品视频一| 免费成人性网站| 亚洲日本国产| 欧美天堂亚洲电影院在线观看| 亚洲区中文字幕| 一区二区三区视频观看| 国产精品久久久久一区| 午夜精品电影| 久久只精品国产| 美女国产一区| 在线观看亚洲视频| 欧美激情无毛| 亚洲永久字幕| 亚洲丁香婷深爱综合| 在线亚洲一区观看| 怡红院精品视频| 国产精品福利网| 欧美丰满高潮xxxx喷水动漫| 亚洲国产日日夜夜| 久久久999国产| 亚洲图片欧洲图片av| 亚洲电影成人| 黄色成人在线| 国产午夜精品理论片a级大结局 | 国产精品一区二区欧美| 免费成人黄色片| 欧美一区二区三区四区在线观看地址 | 欧美电影在线观看完整版| 亚洲天堂成人| 亚洲精品日产精品乱码不卡| 国产视频亚洲| 国产欧美不卡| 国产精品极品美女粉嫩高清在线| 久久久亚洲精品一区二区三区| 午夜天堂精品久久久久| 亚洲影院在线| 亚洲欧美区自拍先锋| 亚洲欧美日韩国产一区| 99精品视频免费观看| 在线观看国产精品网站| 激情综合久久| 91久久久久久久久| 亚洲乱码国产乱码精品精| 99综合精品| 亚洲天堂偷拍| 香蕉视频成人在线观看| 久久久夜色精品亚洲| 美女爽到呻吟久久久久| 亚洲精华国产欧美| 亚洲欧美日本国产有色| 久久福利视频导航| 欧美/亚洲一区| 国产精品久久网站| 激情成人av在线| 亚洲一区二区少妇| 开心色5月久久精品| 亚洲精品无人区| 性xx色xx综合久久久xx| 免费日韩视频| 国产日韩av一区二区| 亚洲精品久久久久久下一站| 亚洲性夜色噜噜噜7777| 另类av导航| 亚洲欧美日韩人成在线播放| 免费观看在线综合| 国产日韩精品久久| 亚洲国产精品久久| 美腿丝袜亚洲色图| 欧美高清视频在线| 亚洲午夜久久久久久久久电影院| 99国产精品久久久久久久| 国产精品免费观看视频| 9国产精品视频| 日韩亚洲欧美中文三级| 欧美久久电影| 午夜久久一区| 久久久在线视频| 亚洲国产精品一区在线观看不卡| 免费视频久久| 欧美电影在线免费观看网站| 亚洲国产精品成人一区二区| 久久在线视频在线| 噜噜噜躁狠狠躁狠狠精品视频| 欧美一区二区精美| 亚洲国产精品一区二区第四页av| 亚洲精品之草原avav久久| 中国成人在线视频| 亚洲高清av| 久久精品夜色噜噜亚洲a∨| 91久久亚洲| 久久久久久久久久久久久久一区| 最新日韩在线| 午夜免费日韩视频| 亚洲一区二区三区在线视频| 久久久亚洲人| 久久漫画官网| 国产亚洲一区二区三区在线观看 | 国产一区二区三区四区hd| 91久久久国产精品| 亚洲风情在线资源站| 亚洲狼人精品一区二区三区| 久久精品国产成人| 亚洲欧洲一区二区在线观看| 欧美精品亚洲精品| 一区二区三区视频免费在线观看| 性感少妇一区| 亚洲精品在线观看免费| 美女图片一区二区| 亚洲人成网站777色婷婷| 亚洲精品影院在线观看| 欧美日韩成人一区二区| 99伊人成综合| 久久久免费av| 91久久午夜| 国产欧美高清| 免播放器亚洲一区| 亚洲精品永久免费| 久久久久久久久久久一区| 国产精品免费观看视频| 久久精品99久久香蕉国产色戒| 欧美一区在线直播| 一本色道久久综合亚洲二区三区| 国产精品美腿一区在线看| 美女999久久久精品视频| 国产一区观看| 欧美一区二区三区免费观看| 老鸭窝亚洲一区二区三区|