• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 303685
            • 排名 - 84

            最新評論

            閱讀排行榜

            首先聲明,我所要談的singleton并非完美的singleton實現,包含各種智能指針和線程安全之類的,那些東西想必大家都已經看過不少了。
            我只是借用最基礎的實現方式,談一個大多數人可能都知道但是卻沒有采用的實現方案——顯性初始化。這是我認為的最優方案。
            下面有些地方會把singleton稱為單體。

            1.現有的兩種singleton實現方法
               1.1惰性初始化
            惰性初始化的singleton的特點有這么些:直到使用的時候才初始化,構造函數私有。代碼可能如下:

            T& GetSingleton()
            {
             
            if ( NULL == t ) t = new T;
             
            return *t;
            }


            或者

            T
            & GetSingleton()
            {
              
            static T t;
              
            return t;
            }

               1.2顯性初始化
            顯性初始化的singleton的特點有這么些:構造函數public,你需要在使用該單體之前new 一下,然后在不再需要的時候delete一下。有關的代碼如下:

            T& GetSingleton()
            {
              
            return *t;
            }


            T::T()
            {
             t 
            = this;
            }


            T::
            ~T()
            {
             t 
            = NULL;
            }



            2.選擇顯性初始化方法的理由
               2.1明確的構造和析構
            惰性初始化,他的初始化時機在第一次調用的時候,但是何時才是第一次調用,這個代碼一多起來,就不是那么好把握的了。
            顯性初始化的時機很簡單,new即存在,并且可以很直觀的調整構造函數的參數。在此一個疑惑的觀點是多new了幾次怎么辦。。。我的觀點是那么顯性的操作,明知道是單體,明知道很關鍵,你還能多new幾下,你就不能判斷一下啊。。。。一般說來,稍微有點基礎的人都不會出這種狀況的,放心的new吧。
            看了大家寫的關于惰性singleton實現的文章,都描述了一個單體析構別扭的問題,因為delete T::Singleton()就像是非法入侵,雖然不會造成什么實質性的危害,但是這本身就是一個語義范疇的悖論(我瞎說的,我連語義范疇都不知道是蝦米),new和delete沒有配對。
               2.2繼承和多態
            單體也會繼承和多態?會哦,而且這通常是由框架本身的約束造成的,我最近的工作就碰到了。在服務器和客戶端的開發項目中,通常會有base模塊,即server & client base,這個模塊使用了單體類A的一些接口,但是這個單體類A在服務器模塊和客戶端模塊可是被分別實現為多少有些不同的S和C,這些實現是無法集成到base的。
            那么,惰性方法是如何考慮這個的呢?第一,static T& GetSingleton方法可以重載嗎?我不知道,沒試過。第二,假設static方法可以重載,但是base模塊使用的是A::GetSingleton哦,那即使重載了也用不上吧。
            以此相對的,顯性初始化的方法就簡單多了:

            //服務器模塊
            *= new S;
            A::GetSingleton();
            //Ok

            //客戶端模塊
            *= new C;
            A::GetSingleton();
            //OK

               2.3OGRE中使用的就是這一種
            最初用到OGRE的時候有些不習慣也不理解,因為他是顯性初始化的,那時候我還使用惰性初始化。提OGRE并不是為了說明顯性初始化好而提供什么論據,而僅僅是想說,看吧,顯性初始化這種方法是有著一個優秀的庫的支持的。

            3.其他
               3.1singleton模板?
            就那點代碼寫了你會死啊,我絕不在這個地方使用模板,多寫個#include和public Singleton<T>比寫個函數和變量更讓我痛恨。
               3.2線程安全
            看了大家一些關于線程安全的singleton,大家都往Singleton函數加鎖了。我說。。。。如果那個單體被用于線程安全的話,僅僅是Singleton函數加鎖是不夠的吧。況且,XP的思想是,有需求,才添加相應的功能,用不上的代碼,能不加就不加。寫多線程程序的情況起始還是不太多的吧。
               3.3singleton和全局變量有什么區別?(小白創可貼)
            其實沒啥區別的,就是一個命名協議的問題(我是完全這么認為的)。
            如果全局變量的命名協議能規定為 g_classname,比如class CBoxManager; 相應的全局變量命名為 g_pCBoxManager的話,不用singleton也可以哦。
            不然的話,每個單體變量的命名都沒個準,這在team work中是一個讓人起小疙瘩的事情。


            PS:加入代碼的DLG里居然沒有C/C++選項,這里可是cpp blog啊^O^~

            posted on 2007-09-14 22:52 LOGOS 閱讀(1612) 評論(9)  編輯 收藏 引用

            FeedBack:
            # re: 談談不一樣的singleton 2007-09-15 02:56 func
            顯性初始化的單件在多線程下還要不要加鎖?惰性初始化的貌似加鎖也會出問題。。。  回復  更多評論
              
            # re: 談談不一樣的singleton 2007-09-15 08:17 LOGOS
            @func
            1.new的時候不用加鎖,一般應該在進入多線程前在主線程把單體new出來
            2.所謂多線程編碼,僅僅是對Singleton()函數加鎖是不夠的,或者也是不必要的。將單體換成全局變量想一想,在獲取全局變量的時候根本沒加鎖這回事。
            多線程要加鎖的地方在對象的算法函數中,而不是獲取對象本身。
              回復  更多評論
              
            # re: 談談不一樣的singleton 2007-09-15 10:06 func
            我說的就是Singleton::GetInstance()函數的加鎖問題,沒表達清楚~  回復  更多評論
              
            # re: 談談不一樣的singleton 2007-09-15 11:58 eXile
            不錯, 和我的做法一樣.
              回復  更多評論
              
            # re: 談談不一樣的singleton 2007-09-15 14:37 func
            汗,第二個回復是在把你回復理解錯的情況下發的,又看了一眼知道你說的了,汗,無視那個回復吧……

            = =  回復  更多評論
              
            # re: 談談不一樣的singleton 2007-10-06 18:48 study
            "顯性初始化的時機很簡單,new即存在"
            單體是不能new的,使用者多調幾次new怎么辦
            你這個就是一個普通的類,不是單體,當然設計之初不需要考慮多線程環境

            另外c++下不能使用類似java下的提前new 出static來 編譯器的問題

            惰性初始化是唯一選擇,也是gof設計模式使用的方式,如果認為效率有問題,可以使用雙重檢測  回復  更多評論
              
            # re: 談談不一樣的singleton 2007-10-17 16:30 func
            樓上應該看一下OGRE的實現,其實這種單件在構造函數中assert的不存在(保證了單件的唯一性),在獲得實例的函數中assert實例的存在(保證了單件的存在性即已被初始化)

            不過感覺缺點就是報錯是在運行時報錯,而不是編譯其間。  回復  更多評論
              
            # re: 談談不一樣的singleton 2007-10-17 16:33 func
            “其實這種單件在構造函數中assert單件實例不存在”

            寫漏了幾個字  回復  更多評論
              
            # re: 談談不一樣的singleton 2007-12-24 23:02 逍遙劍客
            最好所有singleton的初始化跟銷毀都放在一起,因為有些singleton之間是有依賴關系的,必須按特定順序來  回復  更多評論
              
            国产成人香蕉久久久久| 无码精品久久久天天影视| 国产精品视频久久久| 精品久久久久久亚洲| 四虎影视久久久免费观看| 亚洲综合精品香蕉久久网| 久久国产精品99久久久久久老狼 | 中文字幕无码久久久| 99久久国产精品免费一区二区| 无码国内精品久久人妻蜜桃| 99久久精品国产一区二区| 精品国产日韩久久亚洲| 99久久精品国产麻豆| 久久99热这里只有精品66| 麻豆精品久久精品色综合| 久久久久亚洲AV无码专区首JN| 久久免费视频观看| 精品人妻伦九区久久AAA片69| 久久se精品一区二区| 波多野结衣久久一区二区| 国产精品九九久久精品女同亚洲欧美日韩综合区 | 婷婷久久综合九色综合绿巨人| 99久久久国产精品免费无卡顿 | 久久久久久国产精品无码下载| 久久国产一区二区| 日本人妻丰满熟妇久久久久久| 亚洲精品NV久久久久久久久久| 91精品国产综合久久四虎久久无码一级| 久久亚洲AV无码精品色午夜| 日产久久强奸免费的看| 精品国产青草久久久久福利 | 成人久久免费网站| 亚洲国产成人精品91久久久| 久久激情五月丁香伊人| 国产精品激情综合久久| 99久久夜色精品国产网站| 久久伊人精品青青草原高清| AV无码久久久久不卡网站下载| 999久久久免费精品国产| 久久久久99精品成人片欧美| 久久夜色精品国产噜噜麻豆|