• <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>
            隨筆-90  評論-947  文章-0  trackbacks-0

            陸陸續(xù)續(xù)搞了一個多月了,不過其實也就一開始的幾天和最近幾天在好好搞。

            前兩天把 Set、Map 寫完的時候,突然發(fā)現(xiàn)我還是完全沒有理解 STL 的迭代器所玩的花樣。其中的類型萃取我看出來了,其余的都沒有。我這里的迭代器是很土的,每個容器自顧自的(盡管很“巧合”有幾個一樣的接口)。

            String 類我還想繼續(xù)拓展功能。不過沒想好的就是要不要有 Format 功能:如果沒有,使用上或許偶爾會有一點點不方便(如果也不提供數(shù)值和字符串相互轉(zhuǎn)換的函數(shù)的話);如果有,基本上不會去手工解釋 %d、%s 之類的了,那么勢必要用到 sprintf 之類的東西了,那么我的零依賴的設(shè)想就落空了。

            MultiSet 和 MultiMap 有點兒傾向于不提供了,真有需求的到時候去 Set<List<T>>、Map<List<T>> 好了。

            文件在此,點擊下載(還沒測試仔細,可能有不少 Bug,甚至可能某些函數(shù)有語法錯誤沒測到,這點請諒解)

             

            請各位給點意見~

            posted on 2009-11-09 22:01 溪流 閱讀(2166) 評論(32)  編輯 收藏 引用 所屬分類: C++

            評論:
            # re: XL Library Preview,誠征指點 2009-11-09 22:57 | CornerZhang
            既然是在寫自己的容器類和String,又何必考慮stl樣的接口。
            是個DynamicArray時像個DynamicArray的樣子
            是個StaticArray時像個StaticArray的樣子
            是個Stack時像個Stack的樣子
            是個KDTree時像個KDTree的樣子
            是個HashTable時像個HashTable的樣子
            何必要考慮,stl中的那種iterator, begin, end之類,畢竟每個容器的使用方式不一樣,當然接口定義的需求就不一樣

            至于String的格式化輸出,是用語言本有的多參數(shù),自己實現(xiàn)一個printf就行了!  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-09 23:22 | expter
            這種練手 很不錯,,支持  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-09 23:41 | lo
            不想printf 直接抄ctr庫里的代碼就行了  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-09 23:43 | OwnWaterloo
            1.
            "盡管很“巧合”有幾個一樣的接口"
            stl組件之間的通信就是通過這種"巧合"。


            2.
            為什么要零依賴? 這個需求很怪……

            想練習發(fā)明輪子的心情可以理解……
            再給你提供一個練習而又不是重復發(fā)明的東西吧:
            將printf和scanf的解析過程抽象出來。
            這樣,string就只是管理內(nèi)存就可以了。
            format交給別的地方去做。
            相互之間保持正交。

            這樣,format的src和dst可以是FILE*,socket, 以及任何可擴展長度的順序結(jié)構(gòu),比如各種string,std::vector,std::deque,std::list。
            不要將format的功能"埋葬"到你那個string中,太可惜了。將它剝離出來。


            還有stl中的反向迭代器其實是有單獨一個模板的,在<iterator>中,通常不需要自己手工編寫。
            你可以重復發(fā)明它一次,然后應(yīng)用于你的各種容器之上,而不是重復發(fā)明多次。



            3.
            至少std::multiset<T>和 std::set<std::list<T> > 或 std::set<std::vector<T> > 語意都是不同的。

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-09 23:57 | OwnWaterloo
            再給你說個玄乎一些,不那么實際的理論吧……

            一種設(shè)計傾向是"添加直到無法添加"。
            一種設(shè)計傾向是"減少直到無法減少"。

            我傾向于后者。也相信你寫過一些代碼之后會對前者感到反感。

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 00:16 | 溪流
            @CornerZhang

            是。追溯到很久以前,其實我發(fā)明輪子的最初動力是 STL 里的 string 太難用。我就是想提供不一樣的使用方式。也排斥迭代器。最早寫的是一個類 vector 的東西,就不提供迭代器,照樣可以用得很爽。到要寫 List 的時候,就不行了,如果要不暴露結(jié)點,那么必須有類似迭代器的一套東西了。于是回過頭來想想 STL 的這套方式,覺得倒真不錯。所以又反過來學著它了。  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 00:17 | 溪流
            @expter

            謝謝支持!  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 00:18 | 溪流
            @lo

            呵呵,雖然其實一樣,不過也算個手段~  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 00:31 | 溪流
            @OwnWaterloo
            1、這種巧合就是你先前說的GP中的“契約”吧。我心里就是有道坎跨不過去,覺得沒法在語法層面顯式呈現(xiàn)這個契約,,,唉

            2、關(guān)于零依賴
            我知道很多東西不可能做到零依賴,或者做到零依賴代價很大。
            只是我的設(shè)想是,在一套東西里,有一個基礎(chǔ)部分,它只和語言特性有關(guān)、只有邏輯意義,這一部分要保持零依賴。其它實現(xiàn)各種實際功能的東西,可以有選擇的去依賴別的。如果把 Format 看成 String 的一種擴展功能,我本身在寫 String,為了實現(xiàn) String 的一個功能,去使用了現(xiàn)有庫的這種功能,那我不過在做包裝而已,而不是寫東西了。

            也許 Format 也算不上純屬 String 的功能,你后面給我的啟示看上去很有意義……

            3、
            multimap 確實不是這個語義,可能可以勉強湊合吧。只是我想不到非用 multimap 的場合……

            我原本想搞個
            template <typename IFirst, typename ISecond>
            class ComplexIterator

            想先 ISecond ++ 上去,到 End() 了 IFirst++,ISecond=IFirst->Begin()

            然后直接 typedef ComplexIterator<typename Set<List<T>>::Iterator, typename List<T>::Iterator> MultiSet::Iterator

            后來發(fā)現(xiàn)需要迭代器自己確定自己是否是 Begin,于是暫時放棄

            關(guān)于反向迭代器,以及正向的,我一開始想各個容器能否以某種形式提供某一個 ++,-- 的機制,然后統(tǒng)一實現(xiàn) Iterator,但是想不好用怎樣的形式……



              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 00:34 | 溪流
            @OwnWaterloo

            添加到無法再添加 我并不十分支持。
            但是 減少直到無法減少,我也不盡贊同。我覺得 STL 里的東西,就是這種狀況,要什么沒什么,只能根據(jù)已有的少得可憐的東西去湊出來,換句話說,要用到日常開發(fā)中來,經(jīng)常需要自己再包一層。

            我覺得還是以方便使用為原則合理添加一些可有可無的東西比較好。。。

            ——目前的觀點,呵呵
              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 01:06 | OwnWaterloo
            @溪流
            1.
            這是C++的缺陷…… 當初可能沒想到模板會被這么用,所以模板的功能其實還比較弱。
            即使比較弱,也比java和C#強大,它是真正的代碼生成器……
            C#的模板有一些約束,java的根本就是垃圾……
            所以,模板還是很復雜的……

            更本質(zhì)的說,其實體現(xiàn)的是一種ducking type,以單一函數(shù)作為組件之間交互的接口,而不是整個類型。ruby、python、lua這種動態(tài)類型語言都支持ducking type。而C++的模板只支持編譯時的ducking type。
            C++社區(qū)給這種使用方式取了一個新的名字,叫concepts……

            ducking type可能屬于新東西,而且很可能是意外產(chǎn)物(比如C++、python、lua;ruby好像是設(shè)計之初就考慮到這種用法),所以沒有提供專門的、顯示的通過短小的代碼(比如interface聲明)就可以表達的方式。只能通過文檔了……

            說穿了,那些抵觸這種設(shè)計的,要么是偷懶不想看文檔,要么是已經(jīng)學會OO就不想學任何其他新事物,要么就是理解能力不夠……

            心里疙瘩放下吧……
            1.1. 雖然沒有專門的語法支持,但語言還是會檢查的,比如C++編譯時出錯,其他3個語言運行時出錯。
            1.2. 比如python標準庫中,序列就沒有單獨的size()成員。所有的序列都通過len得到長度。已經(jīng)開始向這種思想靠攏了。
            1.3. stl也這么多年了……



            2
            我對0依賴的看法不是"難",而是"通常沒有必要"。
            應(yīng)該盡可能復用已有的優(yōu)秀的代碼。
            盡可能向已有的,還過得去不算垃圾的標準靠攏,而不是自己獨立發(fā)明一套,結(jié)果在實際應(yīng)用中無法融合。

            當然,這和練習編程技巧相抵觸……
            所以我想提出一些建議,既可以練習;并且練習的結(jié)果是可以真正派上用場的。

            比如,你可以考慮實現(xiàn)這樣一個函數(shù):
            int vprintf_parse(void (*handler)(const char* s,void* context),void* context
            const char* format, va_list arg );

            按vprintf的標準去解析format與arg。每處理完一個%就調(diào)用handler一次。
            由handler去考慮將s"輸出"到哪里。
            這樣的話,vprintf_parse就可以用于很多很多地方:傳遞不同的hanlder給它就行。
            當然,你也可以用它來實現(xiàn)string.format。 但一定要將vprintf_parse暴露出來,否則窩在string.format中太暴殄天物了。


            更進一步…… 還可以提供一些讓客戶代碼擴展的機制,讓它自己定義%后的轉(zhuǎn)義符,以及處理方式。



            3
            我的意思是,這種方式是行不通的。
            你要插入的元素是T吧?
            std::set<std::list<T> > 元素是 std::list<T> 哦, 不是T了。
            比較也是按std::less<std::list<T> >比較,而不是T。

            不管multiset的底層實現(xiàn)是rbtree還是rbtree+list,都需要真正定義一個類,將底層實現(xiàn)的接口adapt一下才行。僅僅typedef是不夠的……

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 01:29 | OwnWaterloo
            @溪流
            你就沒領(lǐng)會后者的精妙~_~

            后者的精妙之處在于:增加的東西不可能輕易拿掉 —— 否則會破壞舊有代碼。
            反之,加入原本不存在的東西是很容易的事情……

            如果某個功能確實很常用,你可以再得到這種反饋之后將其作為aux添加進去。
            反之,如果一開始就有某個設(shè)計糟糕的功能存在了,你得到反饋之后也很難將其去掉,并且還要一直維護這個糟糕設(shè)計…… 很惡心


            我很欣賞lua的設(shè)計,將lua庫分為core和aux兩個層次,而不是混淆在一起。
            加上client,總共就是3個層次。
            保持core的精簡對維護是非常重要的。
            aux本身實現(xiàn)就不難,多提供一些對維護影響不大。是否提供完全看需求 —— 這是否是很常見的一種使用方式。

            以unix的機制、策略論來說:core就僅僅提供機制,aux將一些常用策略打包,方便client使用。


            設(shè)計之初就要考慮如何將core精簡到最小。這對日后維護是非常有幫助的。
            一種精簡的大方向就是僅提供機制。比如vprintf_parse,就是一種機制。

            客戶會如何使用它?就是策略了。客戶可以非常多的方式(dst不同)使用它。
            可以預(yù)見:將string作為dst是一種很常見的使用策略。
            仍然可以先不提供它…… 萬一這種估計錯誤了呢-_-
            如果估計正確,大量代碼的使用者向你抱怨"為什么不提供string.format?",你再提供也來得及~

            其他的精簡方式…… 再慢慢總結(jié)吧……

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-10 08:24 | 溪流
            @OwnWaterloo
            這點有點明白了,一開始多了,而以后必須向下兼容,于是肩上的包袱就永遠卸不下來了,是嗎?  回復  更多評論
              
            # re: XL Library Preview,誠征指點[未登錄] 2009-11-10 14:45 | foxriver
            "這點有點明白了,一開始多了,而以后必須向下兼容,于是肩上的包袱就永遠卸不下來了,是嗎?" 支持+贊同KISS原則。

            真正0依賴意義并不大,自己寫的程序難免有BUG,要完善勢必花很多精力,時間,你真的覺得自己花上幾年完善一個LIB是值得的?如果不是研究院,還是按照具體工程來擴展自己的類比較實在些。

            程序?qū)懚鄬懘螅畲蟮母惺苁且郧俺绦蛞磺兴俣葍?yōu)先,有些看起來雜亂的語法,現(xiàn)在都會用簡單慢速明了的語句去表達。。速度越來越不是重點了,結(jié)構(gòu)清晰才是程序長久生命之源。  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-11 14:57 | zdhsoft
            建議使用code.google.com上面開源
            我的也在寫,不過我寫的已經(jīng)在我的很多項目中使用了。面對標準的STL的string,再實現(xiàn)一個實用的string是非常有必要的  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-11 20:04 | 溪流
            @zdhsoft

            google那個規(guī)則怎么樣的?別人可以改我的嗎?  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-11 20:35 | OwnWaterloo
            @溪流
            別人只能check out不能commit。除非你授權(quán)。或者把補丁發(fā)給你。
            用git吧,趨勢……

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-11 22:09 | 夢芭莎
            雖然其實一樣,不過也算個手段~  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-11 22:39 | 溪流
            @OwnWaterloo

            就是傳說中可以打包提交的?
            我以前有一陣子一直在找代碼托管,可惜都開源的,google code 只允許有一個私人項目。。。可我哪有那么多東西能拿出手呀,,于是,只好在自己機器搭了個svn。。  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-11 22:45 | OwnWaterloo
            @溪流
            一個google帳號好像可以建5個項目。每個項目好像可以有2g空間。但是只能放和代碼相關(guān)的哦,否則被發(fā)現(xiàn)了google帳號會被禁用。

            每個項目可以傳文件上去,比如打包好的代碼。

            還有一個repository。原來只提供svn的,后來加入了hg。不過沒有加git。
            svn的repository就是上面說的那樣,擁有者才有commit權(quán)限以及授權(quán)的權(quán)限。
            普通用戶只有check out的權(quán)限。要么只看不改,要么找你要授權(quán),要么給你發(fā)補丁。


            自己機器上做一個svn repository的事…… 我也這樣干過……
            所以很痛恨svn,所以打算用git。

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-13 17:01 | OwnWaterloo
            有個重要的地方忘記說了……
            虛析構(gòu)函數(shù)是不需要的

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-13 21:59 | 溪流
            @OwnWaterloo

            放著讓好事者(也就是將來某一時刻的我自己)去繼承...  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-13 22:03 | OwnWaterloo
            @溪流
            一個虛函數(shù)都沒有,繼承來做啥?

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-13 23:20 | 溪流
            @OwnWaterloo

            定義一個相似的類?  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-13 23:57 | OwnWaterloo
            @溪流
            何時需要虛析構(gòu)函數(shù)?當通過父類類指針delete子類時。
            String這種類型不應(yīng)該作為基類,也不應(yīng)該被多態(tài)使用,所以虛析構(gòu)函數(shù)是不必要的。

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-14 12:32 | 溪流
            @OwnWaterloo

            一般來說,虛析構(gòu)函數(shù)用于告訴使用者該類“可繼承”,是嗎?既然這里沒有什么不可告人的秘密,那么就隨他去好了。(當然,如果有人真要繼承,則必須了解里面的運作機制。這是他自己的事。)這樣理解可以嗎?  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-14 15:26 | OwnWaterloo
            @溪流
            我再使用上面的觀點狡辯一次吧……

            1. 非虛析構(gòu)
            如果、假設(shè)、萬一真的出現(xiàn)了這樣的需求 —— 幾乎不可能 —— 需要被繼承而且以父類指針delete子類。

            還可以這樣:
            class StringDerivable {
            String s_;
            public:
            virtual ~StringDerivable();
            };
            并從StringDerivable繼承。


            2. 虛析構(gòu)
            如果一開始就使用虛析構(gòu),無論是否需要被繼承 —— 幾乎不可能 —— 用戶都必須承擔一個虛指針的代價。


            非虛析構(gòu)對于不需要繼承的客戶來說,沒有額外的代價。對需要繼承的變態(tài)客戶來說,也有辦法實現(xiàn) —— 多一個步驟。
            這是貫穿整個C++語言設(shè)計的一個重要原則:0代價原則。
            虛析構(gòu)無論客戶是否需要,多態(tài)的代價都必須承受。


            設(shè)計不單單只是你做了什么,也包括你沒有做什么。

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-14 19:11 | 溪流
            @OwnWaterloo

            這么說來好像也很有道理...發(fā)現(xiàn)OOP的影子被你砍得一點不剩了,哈哈  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-14 19:15 | OwnWaterloo
            @溪流
            哈哈,被你看出來了……
            我就是一anti-OOP者……

            其實也不是完全是這樣。只是太多人將OOP當作萬能藥了。
            以為OOP的設(shè)計,就一定是好的設(shè)計。OOP成分越多,設(shè)計越好。
            我反對的是這種態(tài)度。

              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-14 19:18 | 溪流
            @OwnWaterloo

            其實我個人基本不怎么會去繼承,也基本不會去多態(tài),我喜歡用組合。但是難保別人不會,所以我經(jīng)常隨手丟下虛析構(gòu)函數(shù)
              回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-14 19:20 | 溪流
            @OwnWaterloo

            那個反向迭代器,是不是可以把正向迭代器當模板參數(shù),在++里讓正向迭代器--,在--里讓正向迭代器的++,正向迭代器的end狀態(tài)當成反向迭代器的end狀態(tài)?  回復  更多評論
              
            # re: XL Library Preview,誠征指點 2009-11-17 20:21 | OwnWaterloo
            @溪流
            某人犯傻去繼承string,那是他的責任。
            沒有必要為了避免他的錯誤,讓所有人讓步,承受虛指針的開銷。

            反向迭代器,我猜的也是這么回時。
            不過具體沒看。
            去看看代碼吧,應(yīng)該不多。
            可能會有一些細節(jié),大致想的時候會被忽略。

              回復  更多評論
              
            久久国产精品二国产精品| 色天使久久综合网天天| 国产精品久久久久久久久软件| 国产精品青草久久久久福利99| 欧美大香线蕉线伊人久久| 久久免费看黄a级毛片| A级毛片无码久久精品免费| 国产精品99久久久久久宅男小说| 四虎影视久久久免费| 久久亚洲国产成人影院网站| 欧美日韩精品久久久久| 久久久久久无码国产精品中文字幕| 久久国产高清一区二区三区| 久久精品国产只有精品66| 日韩电影久久久被窝网| 久久综合亚洲鲁鲁五月天| 日产精品久久久久久久性色| 久久er热视频在这里精品| 久久久久国产一级毛片高清板| 热久久最新网站获取| 亚洲午夜久久久久久久久电影网 | 国产精品久久久久一区二区三区 | 色综合久久久久综合体桃花网| 亚洲AV成人无码久久精品老人 | 老男人久久青草av高清| 亚洲午夜久久久久妓女影院| 久久精品国产亚洲AV嫖农村妇女 | 欧美麻豆久久久久久中文| 77777亚洲午夜久久多喷| 久久精品国产亚洲欧美| 久久久久久久免费视频| 77777亚洲午夜久久多喷| 久久人妻少妇嫩草AV无码蜜桃| 久久夜色精品国产噜噜亚洲AV| 国产精品美女久久久免费| 久久亚洲精品人成综合网| 国产午夜久久影院| 亚洲中文字幕久久精品无码喷水| 国产精品亚洲综合专区片高清久久久 | 国产亚洲精午夜久久久久久| 亚洲欧美精品一区久久中文字幕|