計算機大牛們,看C++有關書籍是不是一遍就看懂了,總感覺自己笨,有些地方需要看幾遍才懂?

本人看C++書籍(一般是國外翻譯過來的),總是感覺自己笨,有些地方需要看幾遍才懂,是不是大牛看一遍就夠了,總感覺自己笨笨噠(effective c++有些地方看不懂就跳過了)


因為多數經典C++書籍的信息密度高,我的經驗是,讀的時候覺得都懂,讀完的時候忘記一半,半年後僅余幾成。只能靠實際應用,才能溫故知新。


C++實在太複雜了,沒必要全懂,大多數人也不太可能全弄懂。

就像你沒必要認識所有漢字,常用的認識就好,遇到不認識的查查字典。

C++也一樣,遇到不會的google下,手邊放本(More)Effective C++,有問題的時候翻一翻。


絕大多數經典或者優秀的技術書籍,通常都不可能一遍看懂,一遍看懂大概只有3種情況:

(1)本身對這一技術領域理解比較深,看同類型書籍的時候和已經已經擁有的知識點兩相參照,能快速理解。

(2)大師級人物,技術功力深不可測。

(3)霸氣逆天的天才。

對於大部分經典技術書籍,如果只看一遍,看完之後很可能和沒有看過效果不會差太遠。如果不實踐,不重讀,再過個1個月,所剩不多。

其實,經典技術書籍的作者都是業界大神級人物,他們寫出來的東西,通常也凝聚了他們自身對這個技術領域的深刻理解。理論上說,如果,如果我們徹底掌握和理解這些書中的思想和內容,是可以讓我們在這一方面大幅提升自己的技術層次,讓自己的對這一領域的技術理解,無限接近於作者的理解。

當然,現實中是不可能的,最難的就是達到這種接近作者的理解水平,對我們大部分人來說,將一本書簡單看一遍,遠遠不可能達到這種理解。這些經典技術書籍,都是好書,如果能夠盡量吃透,是受益匪淺的。

多次做筆記+整理的方法,方法雖然比較笨,但是能夠獲得一些不錯的效果:

(1)首先,在讀經典技術書籍的,需要做筆記(推薦使用思維導圖類的軟體),儘可能將裡面全部的知識點提煉出來,變為很多個知識點,做成筆記。就這樣子,讀完第一遍,做完第一遍筆記。

(2)將筆記背或者理解下來,這個時候,會發現筆記本中自己理解有誤、似懂非懂的部分,這個時候回去重讀相關部分內容,搜索相關拓展內容(googlebaidu搜索一些陌生的技術點,作者可能只在書中一句帶過了),力求將筆記內容和理解修正。

(3)當筆記在我們自己的認為當中,已經比較接近正確理解的時候,嘗試理解作者表達技術的思路,例如作者按照什麼方式闡述這個技術章節,它們之間的聯繫在哪裡,通過某種章節的聯繫,將知識點儘可能串起來。

(4)將筆記繼續背下來,足夠熟悉的筆記後。開始第二遍重讀書籍(第二遍重讀,速度快不少),讀的過程中會發現一些誤解的地方,繼續修正筆記上的錯誤理解知識點。同時,對知識點的認識加深。

(5)納入自己的技術知識體系(如果沒有,可以自己嘗試建立一個),和自己原來的知識筆記融合,通常會出現知識點之間理解上的衝突,再次修正老知識體系筆記和本書籍筆記的內容。

(6)成為知識體系的一部分,儘可能達到舉一反三的程度,盡量往前和往後延伸。

舉個例子,有人說「線程死鎖」,然後:

(1)線程是什麼?(基礎理論知識)

(2)線程的執行環境?(許可權、Linux系統等)

(3)死鎖怎麼產生?怎麼避免解決。(具體技術點)

(4)線程的其他風險點?(餓死、線程安全等)

(5)同類型的東西?(進程線程之間的關係、區別等)

... ...

從一點,展開豐富的聯想,能到一個面。這樣的話,對這本經典書籍的理解,應該有70%-80%,未來哪天很久沒用,將筆記拿出來一看,也相當於重讀了這本書。

雖然方法笨了點,也比較耗時。不過,還是挺有幫助的。


首先很多書用中文寫出來(特別是大陸的翻譯)本身就比英文難看懂,因為英文里很多詞本身都是多義的,很容易聯想,放中文就很奇怪了。比如destructor這個單詞是英文的「破壞」+「者」結合,一看就知道是物件被毀壞時候調用的。但中文的「析構」這個詞就得你去特意記特意反應……

然後C++因為語言特徵導致可讀性極差,就算好好寫,看起來都像天書,就更不要提那些寫作習慣不好的了。尤其是內存指針方面,如果要性能一般就不能寫的太好看(因為C++編譯器很難優化結構),於是關鍵點就會看的非常吃力。

而且這還是假定對方沒有用#define把整個語言重寫的前提下……

所以,看的慢是正常的。

再說關鍵也不是你看的快慢,而是你掌握的如何。如果寫的東西足夠好,那你看的慢些又如何呢。C++本身的知識是有限的,總有看完的一天。


很正常。我一般學一個東西會找來十幾本同一個話題的教材,一本看不下去立刻換一本

關於C++,我可以把當年我買過的C++書名背一遍給你聽:《侯捷系列》、Stroustrup的兩本《The C++》+《The Design and Evolution of》、《Primer》、《Effective系列》、《Essential系列》、《Exceptional系列》、《Efficient》、《Modern》、《Practical》、《Ruminations(沉思錄)》...


我不是大牛,我是渣渣。

我看C++書,從來沒直接看一遍過,所有的技術書,除了代碼大全是連續看一遍以外,別的都不是。

要看一節,開VC,把例題敲一遍,把課後題敲一遍。跑一遍,調試一下,弄清楚到底每一步都在幹什麼。然後自己在突發奇想改動一點點,跑一下看看效果。然後才看下一節。不然就是一頭霧水看天書。

一直到工作三四年以後。還是要經常網上搜索技術點,演算法,手裡還常備一本C++ Primer的英文版當字典用。

從這個層面上,我從來沒把C++書看一遍過,也沒看懂。哈哈。


感覺c++細節性的東西比較多,特別是後面模板多態之類的東西。第一遍看不懂無所謂,了解大意的前提下先略過這些東西,等你需要的時候會返回來看的,一開始過分執著於細節只會鑽死胡同里出不來。這又不是考試不許你翻書,程序員就應該隨時翻教程和參考,一些東西是翻來覆去的看就看懂了。還有一些東西怎麼讀也讀不懂,接觸更深層次之後秒懂,就比如指針和彙編定址的關係,局部變數和棧的關係。


怪不得我一直是菜鳥。

在我看來,寫c++雖然是職業,但更是一種愛好。

實質上只是一種技能,和開車、游泳差不多的東西。

習慣於能用就是了,至今沒好好仔仔細細看什麼專業書。

c++(還包括大部分技術方面的東西),大部分都是一行一行代碼試出來的。

有些東西,就算看了文檔、又看了源碼,最終自己的程序裡面實現不出實際的代碼,有毛用?!

而且還有不少東西曾經實現過,因為幾年下來好久沒用,又tmd給忘記了。

真悲劇!


大學的時候,學得計算機科學與技術,當時對編程一點概念都沒有。上C++課,一個問題百思不得其解,問老師。當時的回答我記憶猶新,老師說:我現在暫時不解答你,未來有一天你自然會知道答案。

後來工作後的某一天,早已知道那個問題的答案的我。想想當時老師的話覺得非常有道理。


就本人而言,一遍是看不懂的,每個入門的人普遍會覺得很難學進去。這門語言入門的確有點難,不懂就問,多看幾遍就好了


沒錯這就是笨。


不要灰心喪氣.

高手也有這段時間.

關鍵在於理解概念.


勇敢寫就是了,不要怕!當然了,c/c++不懂就寫,會有很多陷阱,java好很多。


當年學c編程,那時候沒電腦,一個學期看了12遍。。。


這就對了

你不需要把有關書籍全看懂

你需要使用的是適合自己的適合某一領域的C++子集:)


別讀翻譯書,翻譯書有的不是因為你沒了解原理,只是因為你不知道譯者說什麼而已。他把N種中文句式夾雜自定義的辭彙揉成一句話,讀了3,4遍也沒能把那句話的結構理清楚,你說怎麼懂?

有本書我不點名,他這麼翻譯的:圓柱體的表面法線指向外部,當著色計算僅採用環境光照時,對於某些內部碰撞點將產生cos小於0。

原文意思是cos小於0所以只有環境光照。

完全是因果顛倒啊。。。。。真是的。


笨也要學啊,不學就更笨了


我農村人見識少,進大學才第一次接觸到電腦,我們的教材是全英文的,c語言是kr影印版,上課聽不懂,對著英文字典看了一遍書,由於專業術語,有些地方看了好幾遍也不懂,於是把課本上的代碼抄了一遍,習題更不會做,於是買了習題解答抄了一遍代碼。

這些都不影響我現在做c++碼農,而且別人沒把我的代碼用對導致編譯不過看不懂來問我時會發現我是在有意防止他們做錯。

我不是大牛,不過我覺得當好碼農不需要太聰明,抱著興趣用心去做就可以了。只要喜歡,就算一直平庸著也沒關係。


我也經歷過跟你一樣的階段,翻譯過來的技術書籍很多概念模稜兩可,我看不懂的地方大多數是因為拗口的語言,盯著一句話看很久不懂它再說什麼,總是要把那一句漢語在頭腦里加工很久,再試圖還原回英語才能理解。

自從開始看英文版,就沒有這樣的問題了。可以體會作者最直接的想表達的意思,而不是經過一層模糊的玻璃。

以前看某些翻譯太爛的技術書是一種痛苦,現在看英文版簡直比自慰還爽。


因為你沒有親自實踐過類似的語言,只看書等上手的時候就會發現什麼地方都不懂,指針什麼的理論學了一堆還是不會用。大神之所以大神是他們有實踐的經驗,很多語言一通百通,沒有必要去比較,腳踏實地做好自己最重要。


推薦閱讀:

如何評價call_in_stack這個庫?
Unreal4有哪些令你印象深刻拍案叫絕的設計?
為什麼傳遞函數指針而不是函數本身?
剛開始做leetcode上的題,可以輸出正確結果,但總是超時,怎麼解決?

TAG:程序員 | 計算機 | 大牛 | C | 計算機書籍 |