模板
教程
環境
性能
功能
管理
轉貼： MSDN 訪談錄之C#編程一 rainbow（翻譯）
發表于：2007-06-30來源：作者：點擊數：
標簽：
標題 MSDN 訪談錄之C#編程一 rainbow（翻譯） 關鍵字 C#,msdn 出處 MSDN 訪談錄（MSDN Show） C#編程 C#是一種令人耳目一新且為之一振的編程語言，它設計給C++ 程序員 帶來快速的 開發 能力，而又不犧牲C和 C++所特有的功能和控制。 在今天的這一期里，我們
| 標題 | MSDN 訪談錄之C#編程一 rainbow（翻譯） |
| 關鍵字 | C#,msdn |
| 出處 | |
MSDN 訪談錄（MSDN Show） C#編程 C#是一種令人耳目一新且為之一振的編程語言，它設計給C++程序員帶來快速的開發能力，而又不犧牲C和 C++所特有的功能和控制。 在今天的這一期里，我們將要和Anders Hejlsberg交談，他是微軟一位資深的工程師，一直幫助設計、開發和實現該語言，并發揮其在未來.NET平臺中的作用。我們還要和Jeffrey Richter(著名的編程作家和咨詢專家)交談，他從事C#的工作已經一年有余了。 介紹 Robert Hess，微軟產品經理和“Show”節目主持人。 ROBERT HESS: 讓我們繼續關注理解.NET體系（Architecture）。我們今天將關注新的C#(念“C Sharp”而不是“C Pound”!)編程語言。首先看看MSDN 消息更新欄目。 MSDN 消息更新 由技術編輯Erica Wiechers主持 （略去與C#無關的談話） 技術閑聊（TECHNO BABBLE ） Robert Hess和資深工程師Anders Hejlsberg會面，要討論…??? ROBERT HESS: 歡迎回到這個欄目。好了，就象任何一個要在其上面開發軟件的平臺，為了使這些應用軟件能真正地運行起來，所需要的一個主要東西就是一種編程語言。目前，.NET已經擁有了一種專門為此開發的專用語言，我們稱之為C#。今天和我們在一起的是Anders Hejlsberg，他是微軟一位資深的工程師，在C#語言以及.NET平臺領域都扮演了一個關鍵的角色，在以前的“show”節目里大家都見過他。所以我邀請他到這里來，和大家一起談論C#，談談它是什么，有了它程序員就可以從中得到什么好處，以及它是怎樣真正地影響到應用程序的開發的。 那么，您究竟從事C#哪方面的研究工作，是從什么時候開始的？ ANDERS HEJLSBERG: 在最近大概兩年半的時間里，我們一直在從事C#的研究工作。設計小組由4人組成，而且在這段時間里，我把主要的精力都放在了這上面。要知道，對于一種新的編程語言，我們有許多事情要去做。我想首先也許就是為程序員提供方便，使程序員開發出更多的產品就是最終目標。如今，雖然在產品的收益方面僅僅只是初具規模，但可以說，我們的目標，在某種意義上，不但要使C#具有C++強大的功能和出色的表現，而且還要使其具備簡單易用以及RAD(Rapid Application Development，快速的應用程序開發)語言的生產率。 我們已經做了一些工作，例如，涉及到程序員如何利用更好的工具編寫組件的范疇。如果你看看我們是怎樣寫應用程序的，應該是曾經怎樣寫應用程序的，如果回顧過去，也就是說5年或10年以前，應用程序就是這樣鐵板一塊地被創建的，它和操作系統的唯一交互，你知道，就是進行文件的i/o操作，而且無論如何操作系統都會載入應用程序，接著用戶就與其交互，最后退出?？纯船F在我們是如何創建internet應用程序的，相比起來簡直是天壤之別。應用程序不再是鐵板一塊了，而是由一系列更小的組件構成，它們分別棲息于不同的環境。例如，你可能擁有類似存儲過程(stored procedures)和SQL Server那樣的組件，也可能擁有棲息于瀏覽器中的控件，或者是存在于ASP網頁中的代碼。商業對象生存于中間層，調用整個集合的組件就等于調用該應用程序。于是為了使…… ROBERT HESS: 而當時您明白其中的每一個組件都比5或10年前的一個應用程序更加復雜。 ANDERS HEJLSBERG: 噢，絕對，絕對。同樣，為了減少創建組件的復雜性，不象那種大塊頭程序，每當必須創建其中的一個組件時，就不必另起爐灶，而應該盡量繼承一些早已存在于這些專門的棲息環境(hosting environment)中的東西。如果要寫瀏覽器中的一個控件，就要繼承一個基控件；如果要寫中間層的一個商業對象，就要繼承某些商業對象類；而要想公開屬性、方法和事件等等，就要說明它們是如何通過把屬性與組件聯系一起，以便與棲息環境相結合。而且還要能夠為這些組件撰寫隨組件一起發布的文檔。 ROBERT HESS: 所有的這些只是標準的面向對象的編程，Smalltalk 擁有此特性的時間似乎已經不短了，并且…… ANDERS HEJLSBERG: 嗯，絕對如此，現在并不是不能做這樣的事。但如果注意一下這種今天已經得到了廣泛應用的編程語言，它們實際上并不真正支持面向組件的概念。如果你當初同意我們什么時候談論組件，那么認為它們具有屬性、方法和事件在當今是極其平常的。但如果注意一下C++，就會發現它僅僅提到“方法”這個概念，沒有屬性，也沒有事件?，F在，你可以利用命名模式來仿真它們，也就是說，對于一個屬性，可以用一個get color和一個set color的方法來取代一個color屬性；而要代替類中作為第一個類成員的事件，你擁有的用于接收事件的接口就應該被實現，為了這樣，你就必須處理一些瑣碎的事…… ROBERT HESS:嗯，部分原因是由于C++是基于C的，它只是象預處理程那樣，又由于C本來就不支持，C++也不支持…… ANDERS HEJLSBERG: 是的，實際上我多少認為，你所看到的就是從C到C++再到C#的發展過程。從C到C++，面向對象編程的概念被加進去了。如果你經歷了從C++到C#，那么我會說，面向組件編程的概念也已經被加進去了，而它們之間真的存在著某些相似的地方。就象可以用C代替C++進行面向對象的編程，你也可以用C++代替C#進行面向組件的編程，只不過是更困難而已。用C來進行面向對象的編程是極其困難的，你必須手工地布置V表（虛擬函數表），并且還要處理所有瑣碎的事情。用C++寫組件也確實可行，但必須要為屬性手工地設置命名模式（naming patterns），必須實現事件同步（event syncs），必須具有外部的IDL文件，在文件中可以對棲息屬性（hosting attributes）進行描述，必須具有外部的文檔文件，等等。我們只真正采納了其次一個合理的步驟，它反映了人們是如何編寫應用程序并把其整合到語言中的 ROBERT HESS: 那么，最初的一些目標是什么？僅出自內心的看法，當您第一次著手這個項目時，您要解決的問題和要確定的這種新語言的方向是什么？ ANDERS HEJLSBERG: 嗯，我認為正如您所說，面向組件只是一方面。我想另一個關鍵的因素就是簡單化。使編寫應用程序更加簡單化，不讓程序員做一些瑣碎的事，機器可以代你做。大量的簡化取決于.NET runtime本身，但也取決于語言?；旧?，最終我們所做的，就是讓你把更多的時間、更多的精力放在算法上，而讓系統去做一些瑣碎的事。我認為，許多其它非常關鍵的事情比較現實，我總不能吩咐人們把他們現有的代碼通通扔掉吧。我們必須找到權衡的方法，并不僅僅是你的編程技巧，而且還包括你以前編寫的、早已存在的代碼。因此在C#里，以權衡你技巧的名義，我們努力堅持在與C++的基礎語法最接近、最真實的地方。所以用了C#，C++程序員會立即覺得很眼熟、很親切。 ROBERT HESS: 您的所做的一切應當以C語言為基礎，是否就是當初的思路之一？或者您是否原來就認為，讓我們應與過去徹底決裂，再開始設計一種全新的語言？ ANDERS HEJLSBERG: 嗯，我想這種語言應該以一種嶄新的面貌出現，可是我們明白，必須讓C和C++程序員熟悉這種語言。當然那就意味著在某種程度上，我們必須把語句結構從彎曲的大括號變換成其它一些東西。我們已經打下了一些基礎，但仍然存在著其它某些關鍵的規則，譬如允許寫健壯的軟件，這就意味著象垃圾回收（garbage collection）、異常處理、類型安全這樣的功能，根本地改變了設計該語言的思路，非常難于上手，以后也不容易擴展。我的意思是說，在C++中，C++語言擁有的一個強大功能之一，但有時也同樣是難點之一，事實上您知道，就是沒有類型安全。如果你了解清楚自己要做什么，就會從中獲取巨大的力量，否則，只是自找苦吃。在C++中，獲得一個虛懸指針（dangling pointer）易如反掌。同樣，覆蓋掉一個數組的尾部，或者擁有一個未初始化的變量等等，也是極其容易事情。而我們需要解決這些難題。我認為，我們不能只從 C++著手并擴展它。而真的必須以退為進，以C++的靈魂設計出新的方案，而這些我們已經差不多完成了。 ROBERT HESS: 那么其它語言呢？您注意到這些語言在做了什么嗎？是否它們就是Pascal 或 Modular 2 或 FORTH，您從中得到什么借鑒？ ANDERS HEJLSBERG: 絕對！噢，我們考慮到，嗯，我的意思是說，我本人出身于深厚的Pascal背景，所以，自然要考慮到Pascal, Modula, Oberon, 要考慮到Smalltalk，Java，C++以及所有的語言。要知道，今天它們能生存下來并得到了應用，且或多或少地傳播開了。 ROBERT HESS: 您覺得這些語言的哪些功能比C和C++表現得更出色？而您就可在新的語言中引進這些功能？ ANDERS HEJLSBERG: 嗯，我認為有一件事可以說明，我總是喜歡Smalltalk，就是因為在該語言中，任何東西都是對象。這使程序得到了大大的簡化，因為無論擁有什么樣的數據片，都可以把它當作一個對象從A點搬到B點。一般來說，任何東西都可以對其進行操作?？梢园阉斪鲗ο箢愋?，放在容器中。在Smalltalk實際的實現過程中，如果這樣做的話，程序性能的額外負擔（overhead）就會大大加重。例如，在Smalltalk中，當運算float數字時，每生成一個新的數字，如當1.0和2.0加到一起時，就要分配一個含有3.0值的新對象。而這樣做，代價當然是非常昂貴的。如今在C#中，我們已經進行了一些革新工作，使你獲得了同一樣的利益，而卻沒有額外負擔。只要把float當成float，或者是double就把它當成double使用，就沒有什么代價。但如果把它們視為對象（也僅當這樣做時）,就得給它們分配堆（heap）。因此，就形成了樣相當完美的統一體，既能給您大量的好處，而又沒有程序性能的額外負擔。 ROBERT HESS:C#生成的最終結果的某些結構到底如何？您得到了一個C#程序的文本文件并且編譯它，那么編譯器本身存在著些什么問題，如何設計這些方案以便在使用時更具效率，而這種優化其它語言有可能已經做過，而甚至最終還要生成二進可執行文件嗎？ ANDERS HEJLSBERG:嗯，我們已經做了一些涉及到如何編碼的工作。假如你是一個C++程序員，當然熟悉怎么做，在C++中聲明和實現是分開的。所以所有聲明都放在H文件里，接著在另一些模塊中把它包含進去（# include），然后再在CPP文件中寫出實現程序。在C#中，把它們都寫在同一個地方。這樣，可在那里寫出聲明接著又立即寫出實現代碼。 ROBERT HESS:假如您必須在另外一些文件中采用在main文件中聲明的某些值，那又怎么辦？ ANDERS HEJLSBERG:那么會出現什么情況呢？當編譯時，實際生成的代碼或重新生成的輸出文件都含有兩種代碼：元數據（metadata），符號表（symbol tables）或其它相關的符號信息（symbolic information），而不是僅生成只含有可執行代碼的X86機器碼。在某種意義上，這些代碼變成了自我描述。所以當想從一個代碼片使用另一代碼片時，只要引用它們便可，而這些代碼的自我描述足以讓人們知道在那里有什么類，類擁有什么成員，可以調用什么方法，屬性是什么以及類型名是什么，等等。 ROBERT HESS:那么，是不是象您所指的.OBJ文件或.EXE文件，抑或…… ANDERS HEJLSBERG:嗯，您說的很對，我們在.NET中使用的格式就是PE格式，故可以指向另外的EXE或DLL。我們現在調用這些匯編程序，并基本上用這種語言大量地描述這些高級DLL，它們不僅含有代碼，也含有這樣的信息：說明什么在代碼中，以及這些代碼真正地引用了其它什么樣的匯編程序。 ROBERT HESS:您所說的代碼是指二進制代碼或可執行代碼。 ANDERS HEJLSBERG:嗯，實際上，我們并不直接生成可執行的X86機器碼，而是生成MSIL，也就是中間語言，它由.NET定義，并由JIT（實時編譯器）編譯。 ROBERT HESS: Ok，這樣看來，您擁有了一個可執行文件，其本身與中間語言以及元數據相關聯，而如果我想要在其中一個應用程序里使用它，我只要指向它并說道，嘿，我要借用這些類，借用這些對象，并在這樣的程序中使用它。這使我想起了許多人曾經提過的一個問題，涉及到中間語言存在著潛在的漏洞，有些人可能會攫取這種文件并對其進行反編譯，然后再恢復成當初的源代碼。因此，并非所有的智能特性（intellectual property）都有利于開發者。這方面還有什么問題？ ANDERS HEJLSBERG:嗯，首先，您現在實際上可以用DLL進行處理。這可能有點難，但您可以采用包含X86碼的一個DLL，然后至少把它反編譯成匯編程序。您可做同樣的…… ROBERT HESS:在我的Apple II上，我一直都是這樣做的。 ANDERS HEJLSBERG: 確實如此，我對此感到慚愧。但是運用.NET DLL并把其反編譯成MSIL，也可以做相同的工作。它們并不能直接地被反編譯成C#，盡管您也有可能蒙對，但太難了。不同的地方在于，有著非常多的符號信息（symbolic information）關聯到由C#生成的代碼，以及MSIL，對不起，是.NET匯編程序。例如，你可以從代碼中得知，什么類在這里，它們的成員是什么，等等。這是一個需要解決的棘手問題，因為讓代碼自我描述（self describing）的好處多多，但事實上代碼對自己進行的描述，也同樣使反編譯工具所處理的代碼變得似乎容易理解了。如果我們認識到這個問題，基本上我們要做的，就是創建一個稱作攪拌機(obfuscator)的東西，它會加入并搞亂代碼，使代碼變得幾乎難于看懂，可仍然保留著原來相同的公共接口。 ROBERT HESS:是的，因為您遇到這樣的難題：當采用、編寫這些編譯器程序時，就想讓編譯器理解代碼（或類似的過程等），但卻不想讓人們在同一層次上看懂它們。 ANDERS HEJLSBERG:確實如此，確實如此。我確實想指出，對于一個小程序，實際上可以對其進行反編譯，給出足夠的時間和資源，你甚至可理解它在干什么。然而對于真實世界中的一個應用程序，這卻是一項艱巨的任務。在現實中你最好運行這個應用程序，理解它在干什么，然后寫出它的一個copy。你會很快達到這個水平的。 ROBERT HESS:或許寫出一個更牛的程序，因為您是一個更牛的程序員，對嗎？為了斷定我們的觀眾是否想要著手實現下一個C#項目，他們需要去理解有關C#的一些什么問題？ ANDERS HEJLSBERG:嗯，我想首先你必須考慮到自己的基礎。如果你有現成的代碼體，讓我們假定它是用C++寫成的吧，也許把這些代碼移植到.NET framework的最佳途徑就是使用Managed C++，該C++編譯器隨.NET一起發布。然而，如果你著眼于編寫新的代碼，也就是寫新模塊、更大的模塊，加入到一個應用程序或一個完全了解的應用程序中，而且你精通C++，那么我建議考慮C#。 ROBERT HESS:因此，我們沒有必要說，每個人都必須用C#重寫他們的應用程序。我們在說，人們必須了解他們目前所從事的工程的類型，是否是一個現成的項目、陳舊代碼，并且有時還要用C#寫一些組件，莫非您可以交替地使用C#和C++？ ANDERS HEJLSBERG:噢，絕對。首先，如果你擁有現成的代碼，假定這些代碼是由Windows平臺所支持的任何一種語言寫成的，則把它們編譯成COM組件或DLL，就會獲得與這些代碼很強的交互操作能力（interoperability）。如果要寫專門用于.NET framework的代碼，用于.NET framework的新代碼，當然要用.NET framework所支持的任何語言寫。我們計劃在Visual Studio .NET中發布四種語言：C#、 C++、 Visual Basic 和 Jscript?？墒菫榱伺c產業界和學術界合作，我認為，最新的統計可能不是很準確，但我想總共大約17種不同的語言現在都瞄向了這一個平臺，其范圍一直從APL到Cobol。 ROBERT HESS:那么象Fortran又怎么樣呢？ ANDERS HEJLSBERG:我相信相關的工作正在進行中，可我不能準確地知道到底誰正在設計Fortran編譯器。但關鍵的是，實際上我們已經做了多次示范了，你可以在C#中寫一個基類，并在C++中繼承它，然后再用VB程序創建它的一個實體。在不同的語言之間進行的互用操作是無縫的。我想正是這些性能，使.NET framework甩開產業界中其它競爭對手的產品。(有興趣的讀者可以到去下載Lahey/Fujitsu Fortran for .NET Technology Preview 1，譯注) ROBERT HESS:而且它采用并允許在基礎層次上進行多語言的互用操作。 ANDERS HEJLSBERG:是的，很準確。不過是位于一個很高的層次。您可能會爭辯：現在的語言可以進行互用操作，但只能位于很低的層次，例如，DLL的入口點、具有指針在其中的結構，等等。而我們正在談論到更高的語義層次，是位于面向對象的層次，具有類和接口等等。 |
原文轉自：http://www.anti-gravitydesign.com
