一堆學術派閑的蛋疼總搞語法,沒有一點實用價值。
就不能加點庫嗎?文件系統,通信,圖形...
你把別人都秒了,別人還敢招呼你?唉,明明3你知道他說的不對,你也得點頭說好。低調點,低調點...
re: 全新的美國計算機學科排名[未登錄] chipset 2016-07-21 16:23
隨便拉出一個來就能秒天朝的 北*大學,清*大學到火星...
re: 介紹XXTEA加密算法[未登錄] chipset 2016-04-11 15:32
簡單實用
remove函數并不是真正刪除,而是取代,然后調析構,built-in類型沒有析構函數結果就發現只是向前移動了一下,僅覆蓋而已。
復制元素并非就一定不高效,對于built-in類型,復制比修改指針高效,畢竟程序設計里小對象比大對象常見的多。再說了,大對象哪里有動不動就拷貝的,那是設計失誤。
vector的刪除和插入都建議在尾進行,否則效率低下,因此就沒有.pop_front這種貨。
re: 2015武漢校園招聘歸來[未登錄] chipset 2015-09-28 17:48
@編程小學徒
想考哪個學校,把往年專業課題買來看看,專業課基本就那個范圍,如果能進入復試,把那個學校往年期終考試題目買來看看就能對付筆試。考研時通常考完政治,大家都覺不出好壞,考完英語考數學時考場人數剩下2/3,再考完數學考專業課時剩下1/3。在高中時懷著憧憬,等你讀了大學你會覺得大學真是浪費青春,讀大學對研究生憧憬,等你讀了研究生你會覺得研究生真是浪費青春,但是跨專業報考是得到某個行業門票的一條途徑。
程序是所有計算機課程的實際體現,但有兩樣最明顯,算法和數據結構還有英語。前者是基本功鍛煉縝密的邏輯,后者幫助程序員自學和解決問題更快。
re: 2015武漢校園招聘歸來[未登錄] chipset 2015-09-28 01:30
為了混口飯吃,大家都不容易啊,原諒刷題的同學吧。話說學校里能教啥呀,都靠自己用心,有上進心才是最重要的,否則筆試面試再好也是白扯。從面試官的角度看考試沒有錯,換成我會找有潛力的或者上進心強的。
pool不拼接內存,一塊大內存被分割成很多相等的小塊,此時調用分配一塊較大內存可能失敗,不是因為內存不夠用,而是因為全是分割成小碎塊不拼接導致的。這是Pool的致命傷。再者Pool的效率也高不到哪里,以不拼接小塊換速度的做法不值得提倡。
re: 離開天朝,跑到新加坡了[未登錄] chipset 2015-01-13 19:39
苦海無邊,終于熬出頭了
re: 猜測一下QT的內存管理[未登錄] Chipset 2014-10-16 19:02
很難,除非綁架編譯器,否則怎么能很方便的知道指針在棧上還是堆上?
這種對象指針默認轉換中類型都丟了,析構的時候調用哪個系夠函數?手工刪除時就死悄悄,用智能指針當然也照樣死悄悄。何止對象這樣啊,C++里永遠都是這樣,如果自己想自殺,C++絕對成全你,這是Human Right!
re: 動態規劃解決最長公共子串問題[未登錄] Chipset 2012-12-06 16:39
耗費內存太多
re: 一種簡單的跨平臺信號量[未登錄] Chipset 2012-10-06 15:52
很好的總結
@陳梓瀚(vczh)
謝謝。顯卡藍寶HD5750 GDRR5 1G顯存,中端游戲卡,應該沒問題呀。
看來我得查下后臺看看誰在作怪。
VS2012功能豐富,想干啥都方便了很多。
缺點就是太大了,機器運行起來明顯感覺慢。這微軟弄那么多C#寫的插件塞在里面,狂吃內存還拖慢速度,就為快速開發?我機器配置E3 1230,8G內存雙通道,1T硬盤64M緩存,主板芯片C202,Win7 x64系統,不應該是機器問題,運行別的程序飛快呀。
re: decltype的小“陷阱”[未登錄] Chipset 2012-08-14 17:12
語法越來越復雜,太多的人不得不浪費太多時間熟悉那些花哨的東西,工業語言是這么進化的嗎??C++總會有一天死在這幫家伙們的手里。。。
re: decltype的小“陷阱”[未登錄] Chipset 2012-08-14 17:10
加入thread和一些必要的庫也就罷了。弄一堆形式上的寫法無非少敲幾次鍵盤,形式上看起來爽點,沒有任何實用價值,感覺C++越來越花哨了。
這棵樹如果自己實現就加個父指針,從當前節點向上走到根節點,這條路沿路節點做一下標記,然后從第2個節點向上走,第一次遇到曾經標記過的節點就是最近公共祖先,一直走到根節點都沒遇到就屬于不同的兩棵樹。
這種考試的題目極少有實用價值。
re: 關于hash_map的一點感悟[未登錄] Chipset 2012-07-24 20:23
有時間試試gcc的unordered_map吧,注意版本號4.6.3以后的,4.6.2版本的哈希表比4.6.3的哈希表處理字符竄時慢的不是一點半點。處理大量字符竄,尤其字符竄很長時,因該比SGI_STL的哈希表快得多。gcc的哈希表處理整數可能比SGI_STL的哈希表要慢,主要是Allocator作怪。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-28 00:04
@墨魂
Gnome和KDE都是應用,Linus Torvalds也在公開場合說過KDE做的很不錯,否則在那個C的世界KDE早死了。
Qt的版本升級很快,看來很多人在用(如果沒幾個人用那還有必要頻繁升級嗎?)再想想Qt商業應用得花錢買版權,如果Qt跟GTK+比真的那么差,誰愿意花錢買不好的東西呢?用免費的GTK+(C)或gtkmm(給C++用)豈不更好?
順便說下zjh貼的那段代碼,我真看不出是C的。C89和C94沒有//的注釋符號,C99的規定是何年月啦,微軟的編譯器哪里能升級那么快?Win2K能趕得上嗎?
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-27 17:33
@墨魂
Gnome和Xfce都用C,但是速度差別那么大怎么解釋?很多事情跟語言關系不大對不對。再舉個例子,Chrome,FireFox,IE都用C++來寫,速度和資源消耗是不是也差別很大?這又怎么解釋?
我再舉個例子吧,MTL聽說過吧,做計算的。做數值計算,C和C++沒法跟Fortran比速度,同樣的算法,速度得差20%,但是MTL開發出來后,尤其4.0以后把Fortran都秒飛了,你能說C++不行?那為啥不用C來做,如果C真的那么快?
任何語言都有優點和缺點,否則某種語言早就一統江湖了。。。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-27 17:20
@zjh
Java寫系統還真有,也不是什么畢業設計。你可以谷歌下JNode,除了一點匯編,其它全是用Java寫的。
至于你說把虛擬機固化到芯片里,雖然我沒見哪家這么干,但是我確實聽說有的ARM芯片可以直接執行字節碼。
我們做嵌入式,芯片的計算能力非常有限,內存也跟臺式機沒得比,是很在乎資源消耗的。以前一直認為C++比C慢很多,耗費資源也多,關于C和C++之間的速度差別查閱了很多資料,評測過N次,發現幾乎沒啥差別。
C++的缺點是很明顯的,新手很容易寫出垃圾代碼,速度慢耗費內存多,但優點也很明顯。我們目前做的一個程序大約2百萬行源代碼,C++代碼大約90%以上,C代碼大約5%,還有1%不到的Lua。如果C++的部分也用C來做,你想想源代碼量會有多大,維護起來會有多痛苦...
re: C和C++在兩個小問題上的對比 Chipset 2012-03-27 00:48
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-27 00:31
就說NT吧,不是微(micro)內核,也不是單(monolithic)內核,應該算Hybrid。你可以搜索到NT架構,我也不清楚你說哪一部分。HAL層我估計應該用匯編,據說這些匯編主要來自一個祖籍臺灣人的貢獻(你可以了解一下微軟的歷史,那幾個技術鼻祖)。再上面一層(Kernel mode drivers 和 micro kernel),古老的代碼應該是C寫的,后來改寫的代碼是C++的,再上面也是這樣,古老的代碼是C的,后來的是C++的。其實不僅Windows,Office也是這樣的,最古老的代碼是匯編,后來的用C,C++出現以后所有的新東西都用C++來寫。你不是有win2k代碼嗎,你最好找到我說的那一層看看是不是這樣。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-27 00:13
@zjh
建議你谷歌一下吧,或問微軟的架構師,感覺這玩意沒啥好爭論的。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-26 21:35
@墨魂
如果你還要比,我還能給你舉出更多例子說明C++比C快,耗費內存也少,如果有人說C++比C快耗費內存少,我同樣也能舉出很多反面的例子。。。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-26 21:31
@墨魂
唉,那個排名能說明個啥呀,跟效率沒關系是不是?
其實C++和C速度上沒差別,你可以看下struct和class的內存布局,內存布局都一樣,哪來的速度差別呀。。。
C++唯一慢的地方是虛函數(C沒有),需要查虛表,就一兩條指令的開銷帶來的好處是不言而喻的。。。
至于Gnome和KDE,畫面質量不同,內存和計算量相差那么大,比速度和內存有意思嗎?你咋不拿控制臺給Metro比速度和內存呀。。。
C++是有很多缺點被很多人指責,編譯慢,語法太復雜,新手很容易寫出爛代碼。。。這都是真的,但是不恰恰說明很多人在用C++嗎?否則怎么可能發現這么多問題呢。。。就如同我們天天罵windows一樣,你見過幾個人罵Linux?沒有幾個人用,哪里能發現那么多問題。。。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-26 20:54
@zjh
順便給你掃盲一下吧。微軟的所有產品(除了.net框架的一部分基類用了C#),其余是一色的C++程序,就連C#編譯器都不例外,當然了,個別地方有點Intel匯編。
若干年前Windows Phone上嘗試了一下用C#寫了個軟鍵盤程序,發現速度太慢,最終只好又退回到C++。DOS是用匯編寫的,從Win95以后,都是C++代碼外加少量匯編。Win2K的代碼泄漏過一次,不知道現在網上是否還能下載到,是用C++寫的,這個能看到。
不要覺得WinAPI是些C代碼就認為Win內核是用C寫的,你可以去問微軟的架構師。。。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-26 20:43
唉,我說樓上的那位。Win內核是用C++寫的,少量Intel匯編,你去問微軟的架構師好了,我不解釋。。。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-26 17:43
http://www.phoronix.com/scan.php?page=home這里有很多比較,有硬件的,也有軟件的。
至于你文中提到的C++拋出異常,我真想知道有多大開銷,問題是你拋什么異常,怎么拋異常,怎么處理異常。根據經驗,異常處理會難倒很多C++老手,所以我懷疑你怎么使用異常,會不會很好的使用。
C語言穩居什么排行榜的事情跟效率有關嗎?既然C那么好用為何比排名第一呢?你不覺得你那種論斷荒唐嗎?
至于你提到的圖形庫,GTK+和QT,這玩意怎么比呀。作出的圖形不同的畫質計算量會千差萬別。都是用C寫的界面,GNOME和XFCE速度相差很大,這怎么解釋。即使如此,KDE也未必比Gnome慢哪里去,還在上面那個鏈接,你自己看。
re: C和C++在兩個小問題上的對比[未登錄] Chipset 2012-03-26 17:12
C語法和用法相對比較簡單,C++語法和用法相對復雜,或者說看你會不會用C++罷了。小程序比較快慢沒有意義,上下差不了幾個毫秒,可以看成誤差。我們還是比個比較大的程序吧,你覺得最新的Linux系統顯著比最新的Windows快嗎?前者是C寫的,后者是C++寫的。測試了很多項,都是常用的,除了文件讀寫外(EXT4對NTFS,個人覺得是格式問題),其它項Linux全軍覆沒。在Linux一個網站上比較的Ubantu和Win7,自己谷歌一下吧,我不解釋。
小的容易做到,boundary tags, bitmap, freelist都行,大的需要比較復雜的數據結構,建議用PTrie,你可以參考下DLMalloc,谷歌下。
如果多處理器并行環境,那就非常困難了,傳統的并發控制機制會成為瓶頸,還要小心False sharing, blowup...,你可以參考下JeMalloc,谷歌下。
不像樓主說的那樣,我們這里女程序員就算占不到1/2,肯定超過1/3
re: 快排的一種簡易寫法[未登錄] Chipset 2012-03-05 01:17
需要用到直接插入排序,堆排序和三點取中找支點,然后分割,有點麻煩,到這里去看怎么優化的:
http://www.shnenglu.com/Chipset/archive/2011/08/16/153546.html或者把STLPort代碼下載下來去里面找,原理是一樣的。
我主頁上有常見的14種排序,如果單線程的話,快排是最快的,多線程需要重新設計,太麻煩,最容易實現并行的排序個人認為是歸并排序。
re: 快排的一種簡易寫法[未登錄] Chipset 2012-03-04 21:34
你的速度不行,數據結構書上的更垃圾。
re: 可悲的人情人節,找工作求助[未登錄] Chipset 2012-02-15 17:02
如果你家是東北的,我可以推薦你來我們這邊做嵌入式,不知道你是否有興趣。
re: 一個老鍋爐工的故事[未登錄] Chipset 2012-01-28 20:37
@123
啥意思啊,對天朝沒信心?
re: 蝸牛排序--我見過的最慢的排序 Chipset 2012-01-09 18:21
@.
猴子排序理論上最壞情況下時間復雜度為無窮大,最好情況為O(n),一般情況為O(n*n!)。可見確實比我的蝸牛排序慢。
猴子排序偽代碼如下:
while (沒有排好序)
打亂當前序列的順序;
很同情博主經歷,很佩服博主自強不息的精神。
工資跟當地生活水平相關,跟做的事情相關,跟周圍環境或者說公司本身相關。
估計你的某句話或某幾句話得罪了某幾個看客了,以后說話謙虛點,做人低調點就是了。
唉...
內存管理系統的事情,對C++要求這么高,是不是太過分了。new就是一個殼,調了API。當然,最好別重載全局new,局部的我看也最好別重載。一般程序new就足矣,多CPU并行和吞吐量的程序,只能自己來管內存,否則慢也就罷了,還出一堆碎片。
系統管理內存都做不到完美,指望語言級別依賴于實現的new能做好?看看系統內核每次升級,有多少改動發生在虛擬內存管理器...
Douglas Comer也得罪你啦,講點道理行不?
Linux Kernel也大量用到了動態內存分配。既然操作系統內核都不怕動態分配內存造成碎片,應用程序為什么要害怕?
暈,什么時候操作系統都不怕碎片啦?linux內核原來用buddy,2.2以后來用slab因為啥原因啊?類似情況還有FreeBSD5.0, NetBSD4.0和Solaris2.4以后。
re: C++ __int64用法[未登錄] Chipset 2011-10-20 16:40
__int64是Win的,不是C++的,int64_t是C++新標準才有的,但是新標準還沒下來
long long是C的(C99),也不是C++的。
可以自定義兩個32位整數,一個存高位,一個存低位,一個struct結構,就有了64位
看了三篇文章。不知道該說啥好,單CPU,DLMalloc足矣,其它我都不看好,最不看好用完最后一次性釋放的內存池,原因不解釋。
多CPU,ptmalloc3,或glib里的內存管理器(以ptmalloc3為基礎的改進),谷歌的TCMalloc,還有Free BSD的Jemalloc,以及Hoard。多CPU,碎片率低,好的線性加速比是關鍵,Jemalloc很強。TCMalloc看上去像個多CPU的自有列表內存管理器,加速比也不錯,且有垃圾收集,但是啟動速度跟啟動Java虛擬機絕對有一拼...這些都是免費的。至于那些要錢的,我懶得一提...