• <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>

            luke

              C++博客 :: 首頁 :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              3 隨筆 :: 0 文章 :: 0 評論 :: 0 Trackbacks

            2009年4月1日 #

            以前一直沒有關(guān)心std::endl的工作機制,最近突然想一窺究竟,于是下載了sgi的stl(http://www.sgi.com/tech/stl/)實現(xiàn),
            于是恍然大悟,對其實現(xiàn)者真是敬佩。

            在文件Ostream中class basic_ostream 有如下成員函數(shù):

             basic_ostream& operator<< (basic_ostream& (*__f)(basic_ostream&))
                { return __f(*this); }

             basic_ostream& operator<< (_Basic_ios& (*__f)(_Basic_ios&))
                { __f(*this); return *this; }

             basic_ostream& operator<< (ios_base& (*__f)(ios_base&))
                { __f(*this); return *this; }

            然后有如下全局函數(shù):
            template <class _CharT, class _Traits>
            inline basic_ostream<_CharT, _Traits>&
            endl(basic_ostream<_CharT, _Traits>& __os) {
              __os.put(__os.widen('\n'));
              __os.flush();
              return __os;
            }

            可見原來我們經(jīng)常使用的cout<<.....<<endl中的endl竟然是一個函數(shù)指針,由此我們還可以找到如下定義:

            // basefield manipulators, section 27.4.5.3
            inline ios_base& dec(ios_base& __s)
              { __s.setf(ios_base::dec, ios_base::basefield); return __s; }

            inline ios_base& hex(ios_base& __s)
              { __s.setf(ios_base::hex, ios_base::basefield); return __s; }

            inline ios_base& oct(ios_base& __s)
              { __s.setf(ios_base::oct, ios_base::basefield); return __s; }

            原來這些我們經(jīng)常見到的C++流輸出格式符居然都是一些函數(shù),都是通過重載<<操作符來實現(xiàn)的。

            posted @ 2009-04-01 15:15 盧克 閱讀(859) | 評論 (0)編輯 收藏

            2009年3月13日 #

            今日粗看boost的代碼,發(fā)現(xiàn)很多類都繼承noncopyable,以下是noncopyable的代碼:
            class noncopyable
              {
               protected:
                  noncopyable() {}
                  ~noncopyable() {}
               private:  // emphasize the following members are private
                  noncopyable( const noncopyable& );
                  const noncopyable& operator=( const noncopyable& );
              };

            這里的設(shè)計思想是讓子類繼承,但是阻止子類調(diào)用賦值和copy構(gòu)造函數(shù),有什么用呢?
            寫代碼的時候我經(jīng)常喜歡用singleton模式,比如那些工廠類,管理者類之類的,但是寫這些
            singleton的時候當(dāng)然是希望全局只有一個,而且不希望別人在用的時候又自己創(chuàng)造一個,往往
            就要每寫一個singleton類就要在類的declaration中把它們的構(gòu)造函數(shù),賦值函數(shù),析構(gòu)函數(shù),copy構(gòu)造函數(shù)隱藏到
            private或者protected之中,這樣真的很累。
              現(xiàn)在好了,只要讓這些singleton直接繼承noncopyable就ok了。這樣至少可以不用多寫賦值和copy構(gòu)造
            函數(shù)了;構(gòu)造和析構(gòu)函數(shù)看情況而定了。

            class noncopyable的基本思想是把構(gòu)造函數(shù)和析構(gòu)函數(shù)設(shè)置protected權(quán)限,這樣子類可以調(diào)用,但是外面的類不能調(diào)用,
            那么當(dāng)子類需要定義構(gòu)造函數(shù)的時候不至于通不過編譯。但是最關(guān)鍵的是noncopyable把copy構(gòu)造函數(shù)和copy賦值函數(shù)做成了
            private,這就意味著除非子類定義自己的copy構(gòu)造和賦值函數(shù),否則在子類沒有定義的情況下,外面的調(diào)用者是不能夠通過
            賦值和copy構(gòu)造等手段來產(chǎn)生一個新的子類對象的。舉個簡單的例子:
            class Test : public noncopyable
            {
            };

            void main()
            {
               Test a,c;
               Test b(a);  ///<------(1) error

               c = a;     ///<------(2) error
            }

            如果Test類沒有繼承 noncopyable,那么(1)和(2)都可以通過編譯,但是一旦Test繼承了noncopyable,則(1)和(2)都通不過
            編譯,從而可以防止調(diào)用者寫一些錯誤的代碼,這不正是我們做singleton對象所需要的嗎?



            posted @ 2009-03-13 11:00 盧克 閱讀(6259) | 評論 (0)編輯 收藏

            2008年10月13日 #

              我的service程序在windows XP 和 windows2003下工作正常。但是在vista和windows2008下安裝的時候總是在啟動service這一步的時候失敗。一直沒有找到原因。這兩天集中精力,終于找到了原因,但是卻解決不了這個問題。
              做了如下幾個測試:
              (1)把ServiceMain開始部分做成一個console程序,運行OK,這說明主要部分代碼邏輯沒有問題。
              (2)去掉ServiceMain()中的大部分功能代碼,做一個簡單的service,運行OK,這說明原來的service安裝和啟動部分代碼也沒有問題。
              (3)分步排除各個dll。
              最后發(fā)現(xiàn)導(dǎo)致無法啟動的罪魁禍?zhǔn)拙尤皇莑ibmysql.dll,我如果在程序中屏蔽掉所有mysql的調(diào)用,等于程序啟動的時候不加載libmysql.dll,那么就可以順利啟動,接著更換到最新的libmysql.dll(版本5.0.67),仍然是啟動不成功;后來切換到一個同事的老版本libmysql.dll,居然可以啟動成功。5.0.67版本libmysql.dll (opt)的大小是2M多,而我同事的那個libmysql.dll才1M多,難道他的版本是mysql4.x ?
              究竟是什么原因?qū)е逻@個問題的?


            posted @ 2008-10-13 17:06 盧克 閱讀(245) | 評論 (0)編輯 收藏

            僅列出標(biāo)題  
            94久久国产乱子伦精品免费| 久久久久亚洲AV无码去区首| 国产精品久久久香蕉| 久久激情亚洲精品无码?V| 亚洲国产成人久久笫一页| 伊人久久五月天| 久久99精品久久久久久hb无码 | 国产69精品久久久久99| 久久久久国色AV免费看图片| 久久综合九色综合欧美就去吻| 日本WV一本一道久久香蕉| 日本强好片久久久久久AAA| 久久精品免费观看| 99久久综合国产精品免费| 久久乐国产综合亚洲精品| 狠狠色丁香婷婷综合久久来来去| 久久99国产综合精品女同| 色综合久久中文色婷婷| 精品国产日韩久久亚洲| 久久噜噜电影你懂的| 久久精品国产亚洲αv忘忧草 | 国内精品人妻无码久久久影院导航 | 久久亚洲精品无码aⅴ大香| 狠狠狠色丁香婷婷综合久久五月| 亚洲国产精品成人AV无码久久综合影院 | 亚洲国产精品成人久久| 九九久久精品国产| 国产欧美一区二区久久| 中文字幕久久久久人妻| 亚洲精品无码久久不卡| 久久se精品一区精品二区国产| 久久精品aⅴ无码中文字字幕不卡| 午夜精品久久久久成人| 热综合一本伊人久久精品| 伊人久久大香线焦综合四虎| 久久综合九色综合网站 | 性高湖久久久久久久久| 国产精品久久久久a影院| 久久青青草原精品国产软件| 99久久国产热无码精品免费久久久久| 久久久久亚洲AV无码永不|