導語:日前網絡上關于C++程序員是否應該對匯編語言有一定的掌握程度的問題討論比較激烈。反對的觀點大致有幾點: 1.對于普通軟件開發人員來講,關注于上層實現,關注于功能和產品才是主要,匯編也用不到;2.很多的C++程序員不懂匯編,也成為了某公司某項目組主程序、核心研發,因此匯編可以不學不用;3.絕大多數C++程序員還是在做上層開發,絕大多數項目也是上層開發,不了解底層也能賺到大錢,而且是更多的錢;4.做底層,比如:逆向、破解、寫病毒等,很多致力于這層的程序員,感覺整天昏天暗地,無數的重復勞動也沒賺到大錢,覺得沒意義;5.對于做C#、Java、WEB等領域的程序員們,大多數不會去關注底層實現,他們照樣過得很好,以此類推,匯編也是可以不掌握的;6.匯編語言幾乎是不跨平臺的,于是就算掌握了某個平臺的匯編,但在匯編語言上,例如語法、機制等還是有局限性。
本文作者作為一名C++程序員也參與了討論。作為站在支持一方,他就上面幾種反對的觀點的看法(可以總體分為幾個關鍵點:利益、收入和興趣)以及個人的體會分享了看法,有一定參考價值。
以下是根據他的文章整理而成的內容:
從上面幾種反對的觀點來看,可以總體分為幾個關鍵點:利益、收入和興趣。我不打算將這三個關鍵點分別進行針對性闡述,因為它們之間都是息息相關分不開的。對于利益和收入上來講,的確是有很多公司的高職位且收入不錯的程序員并不了解匯編和底層,這樣也不代表他們沒有能力,而往往他們是非常有能力的人。這樣一來似乎和我個人的支持類的觀點有所沖突,但我認為這個沖突可以用追求二字來化解。為什么可以用追求來化解呢?因為追求可以是任何領域、任何方向、任何目的和任何標準的,因此也就是我前面所說的,歸結到根本,掌握不掌握都沒有對錯。
我們進入這個行業,從事了編程工作(大多數程序員都是編程開發做起的)。我相信很多程序員的初衷,都是對編程開發有很大的興趣,興趣驅使著我們熬夜,驅使著我們研究, 驅使著我們進步。對于C++程序員,我相信興趣占有很大的比重。那么,我們來舉幾個例子:
你應該看過《深入C++對象模型》這本書吧,這是一本非常細致和美妙的書,我想你應該有這樣的感受。那么在此基礎之上,你有過更多的思考嗎?這本書里都是以實例和理論來進行講解的,實例是以C++語言進行描述的。于是你是否有想知道在具體的編譯器和平臺下的這樣一些疑問:
1.this指針是怎么傳遞進成員函數的?成員函數和普通函數以及靜態成員函數有何區別和聯系?
2.透過語法,成員函數和類在內存中有什么聯系?對象和成員函數有何種聯系?
3.函數間的調用原理,是怎么實現的?
4.__cdecl、__stdcall、__thiscall和__fastcall這幾種函數調用方式,在本質上有什么區別?具體是怎么實現的?
5.虛函數、多態和繼承在本質上的體現,以及這些機制在底層是怎么實現的?
除此之外,你在學習和使用C++的時候,我想你還會在乎一些細節,例如:
1).遞歸函數一定會導致低效?編譯器針對遞歸函數會不會有什么樣的優化?你怎么知道這些優化細節?
2).對于這句代碼:int b = a > 0 ? 100 : 200; // int a; 編譯器會有什么細節上的優化?這句代碼會有比較并跳轉的過程嗎?
3).對于這樣的代碼:
view plaincopy to clipboardprint?
1.#include <stdio.h>
2.int a = 10;
3.int main( void )
4.{
5. printf( "%d", a );
6. return 0;
7.}
在VC下,開啟全局優化,全局變量a還存在嗎?你怎么通過本質的論證來證明?
4).對于:float a = 100; int b = a / 30; 在VC下,你會不會懷疑這兩句代碼背后會存在函數調用?如果有,調用了什么函數?為什么?
5).對于__declspec( thread ) int g_nNum = 0; 你知道g_nNum++;這句代碼背后的具體實現機制嗎?
6).對于調試,你會怎么根據自己記錄的程序崩潰時的堆棧現場及其它信息來錯誤跟蹤查找呢?
7).對于開發游戲來說,你怎么知道外掛是怎么修改游戲程序的,修改了哪個地方呢?
8).你要怎么熟悉編譯器的優化細節,怎么寫出適應它的代碼,怎么寫出比它優化得更好的代碼?
還有很多這樣上層開發的例子,這里就不一一列舉了。從上面列舉的這些疑問,我想作為一名C++程序員,熱愛編程開發的程序員來講,你都想知道其中的原委。作為上層開發者,是應該關注上層的功能開發和產品方面的東西。但是我個人覺得,本著技術,本著這份熱愛,本著自身的技術發展,了解更底層一些,有助于上層開發的通透性,以及全局的掌控力度。從我個人的感受來講,當把握了關鍵細節以及全局設計之后,任何地方出了問題,都能很及時的反應并予以追查和處理。在當前的編譯器技術上,已經非常強大了,很多細節可以放心的交給編譯器來優化和處理。但是我想,編譯器不是萬能的,人才是智能的。掌握不是必然,但掌握了會更好。
對于初學者乃至工作了一定時間的程序員,對于C++,很多處于C++語法的層面,在語法上的條條款款使用得得心應手,問其本質,可能就缺乏一二了。我個人的經歷來看,在掌握語法之后,在向下關注一下語法背后的具體實現,會通透很多。你會在內存上、數據上和程序的各種底層運行機制上會有深刻的認識。這也就是為什么去海邊玩兒,還要潛水去看看海底世界。錯過了海底,你會失去很多精彩,而這些精彩我想也是作為程序員應有的追求之一。
對于Java、C#以及WEB類領域的程序員,我想匯編可能相對遙遠一些。在這方面的關注也會相對少一些,但結合前面的觀點,作為程序員這個角色,都是讓自己的程序在機器上面跑起來,那么我想這之間的諸多底層的疑問可以作為程序員的一種興趣來研究。目的也是為了讓自己更通透,更熟悉自己的平臺。我不知道怎么表達通透二字,就我個人的感受就是,能夠從現象聯系到本質實現,并且能夠從本質實現勾勒出一幅很清晰生動的圖像在腦子里,一切都一目了然盡收眼底。有點居高臨下,望長城內外,惟余莽莽的那種寬廣的感觸。
對于本身就處于底層開發的程序員來說,無可厚非,掌握匯編就是必須的了。但是澄清一點,本文的觀點更多的是從興趣和通透性上出發,對于底層開發者可能會覺得底層有一定的枯燥,特別是整天破解、逆向等工作,非常多的體力活,從我幾年的業余破解和逆向經驗來看的確是這樣的。但是我覺得,破解和逆向只是領域之一,我之所以破解和逆向,很多時候是處于興趣和為了對上層進行更本質和合理的解釋。所以,上層和底層結合,才是我的根本目的,也是本文想推崇的一種思路。
綜上所述,我的觀點是C++程序員乃至程序員,不管是作為興趣還是工作,掌握或者了解一下匯編都是有一定必要的,但不是強制性的,也正所謂需求和追求不盡相同罷了。因此,不要問別人到底是否應該關注一下底層,掌握一下某種匯編語言,答案很明顯。