利齒C sharp代替C++？

c++ 現在，對於一個進行中項目開發的公司來說，選擇一門Windows下的開發語言已經不再像以前那麼容易。C++曾經是商業開發最好的選擇，但是現在，開發人員們已經沒有時間，也沒有耐心一遍遍重複“編寫代碼——編譯——排錯”這樣一個無休止的迴圈，也不再想去一次次地修補多年前編製的程式裡的漏洞，他們已經厭倦了這一切。雖然Windows下的C++編程相對來說比較容易，但網路時代的飛快節奏已經不允許他們慢條斯理地跟自己的開發工具較勁。他們需要一個高效的、安全的開發工具。
　　相對於C++而言，Java的優勢是開發週期短、代碼安全（因為沒有指標），以及平台無關性等。然而對於底層開發，Java還是不夠理想。儘管這樣，還是有眾多的程式員開始選擇Java作為開發工具，這其中當然包括很多原先Windows的開發人員。也許正因為這樣，微軟才匆忙發行了其.NET SDK(軟體開發工具箱)的beta預覽版。該開發工具下載下來後共有86M，它向我們展示了未來Windows環境下的一個新開發理念。在工具包中包含有一個C＃編譯器，它是一種新的程式語言，被命名為“利齒的C”。不知這一利齒，會把Java咬成什麼樣子。不過對於C++，C＃似乎有趕盡殺絕之意。

　　C++上長出的利齒
　　這款微軟打制的另類C++對於那些投身於Windows C++開發的人來說，應該說是一大福音，因為它減輕了C++給程式員帶來的痛苦。它不同於C++，當然也不同於Java，它使得訪問Windows本身所具有的各項服務（包括網路對象、Uis和網路通訊）變得非常容易。和Java一樣，C＃通過避免一般的編程錯誤和自動資源管理，使得C＃的穩定性得到了極大的增強。
　　如果已經熟悉了C++，那麼學習C＃要比學習Java要容易得多。C＃不是由微軟來管理，而是由ECMA（歐洲電腦製造聯合會）來管理，和JavaScript一樣。ECMA是一個獨立的實體。並且，然beta預覽版裡沒有做什麼暗示，但是有訊息稱微軟將發行其它作業系統版的.NET和C＃（beta版只能在Windiws2000上運行）。如果這是真的，那麼不久的將來，C＃很有可能大行其道。


　　有批評家告誡說：.NET和C＃只不過是一種已經被宣布或銷售但還沒有正式生產的新型軟體。即使是這樣，也不能阻止人們使用C＃的熱情。我們用它工作了近一個月，發現它的確要比我們以前使用過的編譯器好得多。事實上，因為這款編譯器表現確實非常的好，以至於現在已經有開發人員在Internet和Web論壇上進行一些C＃的代碼交換（比如：http://www.csharpindex.com）。
　　現在已經出現了一種編寫C＃的編輯器，並且其它從事商業編輯器的商家也正在測試其對C＃的支援情況。一個好的代碼編輯應該使得編寫一個Web伺服器變得很容易。現在微軟正在聯合Vertigo Software，準備再推出一個實用的.NET電子商務示範產品。

　　C++癥結何在？
　　Java的創始者認為，C++對於程式設計的放任政策給了C++開發人員予極大的自由。他們不僅可以輕鬆訪問系統資源，甚至對於語言本身也可以進行重新修改。這也許算得上是一大特色，但也正是這一大特色毀掉了C++本身。用C++編製的程式，代碼的錯誤有可能導致系統漏洞，導致非法或者惡意的記憶體操作。不僅如此，因為它的問題很難排除，所以令很多程式員大傷腦筋。
　　Java應用程式的穩定性，主要得力於其摒棄了C++的一些諸如人工記憶體定位、指標（直接指向記憶體）、瞬時變數和超載管理員等功能。此外，其自動的記憶體管理、方便的平台無關性以及大量的預定義Java對象，都使得Java開發人員對於對象的定義和使用都變得非常容易。
　　應該說，Java卓越的設計使得企業軟體的開發有了很大的改變，但是由於它背離了C++的文法，使得它很難被C++的開發人員們所接受。這在很大程度上阻礙了其發展和普及。
　　和Java相反，C＃則是將C++向類似Java的方向擴充，這些擴充包括自動記憶體管理、對象壽命管理、解釋執行、輕鬆訪問外部對象和簡化對象的建立。C++有益的概念被Java摒棄了，比如超載管理員和參考變數，而C＃則保留了這些概念。被Java拋棄的指標在C＃中也得到了保留，只不過它不再像以前那樣無所不能。它僅被使用在那些被標記為非安全的程式碼片段裡。

　　向C＃移植
　　從C++轉變到C＃，就像從人工方式轉化到自動方式一樣？在C++裡，必須為對象分配一明確的空閑記憶體，而在C＃裡，記憶體的分配則是自動完成的。被C＃的對象佔用的記憶體在該對象不再被使用時，將被釋放（即記憶體垃圾的回收技術，這是Java裡被人們廣為稱讚的一項技術）。
　　在C++裡，為了訪問一些系統服務，就必須在檔案頭裡包含進許多檔案，而這些檔案中的大部分，在對象設計中，根本用不上。在C＃裡，系統服務被透明地封裝在一些和C＃相容的對象裡。在C++裡，要把C++對象變換成Windows的COM（Component Objec Model）是非常困難的，而在C＃裡對象會被自動地轉換成.NET模式，並且可以從各種.NET語言裡進行訪問。
　　.NET層保證了對象可以在各種語言中使用，所以就沒有必要進行資料的轉換或者外部對象的轉換。
　　現在，使用C＃最大的困難就是要求程式員習慣於在不用離合器的情況也能換檔。也就說，一旦調整過來以後，C＃將要比C++容易駕馭得多。Java需要其C++開發人員們學習的是一種新的做事情的方法。而對於轉向C＃來說，C++的開發人員們放棄的只是在系統開發過程中的那些用代碼編寫的難看的對象和糟糕的記憶體管理。而他們還依舊可以使用指標和參考變數，這給了C＃開發人員們一種直接、簡單的訪問外部模組（包括32位的Windows動態連結程式庫）的途徑。
　　把Windows C++應用程式轉換成Java應用程式將是一件非常痛苦的事情，但是如果把它轉換成C＃，.NET多語言交叉的功能將使這一切變得比較容易，並且轉換後的應用程式將會在穩定性上得到很大的增強。微軟似乎對於輕鬆訪問現有程式方面下了很大的功夫，效果也很不錯。
　　除了模組要求具有很好的效能外，要把現有的C++應用程式移植到.NET，選擇C＃將是一個明智之舉。微軟的.NET擴充到Visual C++，使得其和C＃代碼整合變得非常的容易。

　　C＃是繼承人
　　C＃的產生是因為微軟在.NET上需要一種類Java的語言，而Java本身卻不能勝任這一需求。C＃太像C++了，以至於它很難給人帶來體驗新事物時的那種興奮。不過，可以相信，絕大部分的C++開發人員將會因為C＃保留了C++中大部分其喜歡的、強大的、令人激動的功能而選擇使用它。不管微軟的動機如何，就C＃直接由ECMA來管理這件事，還是很令公眾滿意的。這使我們有機會得到非微軟的C＃工具和編譯器以及其它機構發行的資源。
　　第三方的C＃開發工具將不需要從微軟獲得語言許可認證，這就會使得這些工具的價格維持在一個較低的水平。相反的，因為Sun使其Java脫離標準的軌跡，以至它只能孤軍奮戰，在Java發展的道路上獨行。

　　因為.NET依賴於C＃，且只能在Windows上運行，所以微軟在企業級的開發上實際已經落後於Sun。不過，由於其.NET架構是獨立於特定語言的，所以將使得微軟在競爭中也能佔到了一部分市場份額。即使是在beta版裡，開發人員也可以使用C++、C＃、Visual Basic、JavaScript、 Visual FoxPro來開發.NET應用程式。他們可以譯成一種所謂IL（中繼語言）的代碼語言，並且共用一個定義在資料無關技術上的架構。因為沒有VB、C＃和JavaScript對象，而只有.NET對象，所以開發人員可以使用幾種語言代碼進行混合編程。
　　對於傳統編程來說，在項目開發中，開發人員們都喜歡選用同一種語言，因為這樣便於不同開發人員間進行串連。現在.NET將不再有這種限制，開發人員可以把C＃、VB、C++和JavaScript放在同一代碼編譯器裡，而.NET層可以把這些塊捏合在一起，並且還會有更多的程式語言將可以.NET中使用。開發人員可以選用自己最熟悉的和最喜歡的程式語言來進行開發。這就意味著可以使用盡量少的時間、更低的培訓費用、明了簡潔的原始碼，這一切都將使得開發人員的開發過程變得非常愉快。
　　對於C＃來說，其完成的一項首要工作是使得C++的開發人員們能夠訪問其.NET架構。這可不是一件容易的事，因為.NET的目的是要成為Windows公司專屬應用程式開發的核心。在佛羅里達州奧蘭多舉行的專業開發人員大會上，.NET初次亮相，微軟向世人展示了.NET不僅是獨立於硬體的，而且在多平台間互動也很方便。
　　微軟對於其.NET的移植計劃一直保持著沉默，當然使其運行在Windows下是首位的問題，但我們懷疑微軟是否會將其儘快地移植到Solaris和Linux上。一旦.NET擴充到Windows以外的其它系統，那麼C＃將成為Java真正的強有力的競爭者。到那時，C＃將成為C++在Windows企業開發中的真正繼承人。