RSS 2.0 Feed
2004-04 Entries
摘要:   Microsoft新发布了Visual C++ Toolkit 2003,一个免费下载的“简装版”Visual C++,包括了C++编译器,标准C函数库和C++标准库STL。因为没有MFC, ATL和WTL,如果要编写Windows程序的话可能需要额外下载Windows Platform SDK;Toolkit本身也没有.NET Framework SDK,下载大小为32Mb(包括一些Sample)。    Visual C++ Toolkit 2003使用的是Visual Studio.NET 2003 Professional版本的C++编译器,所以它支持使用/CLR编译Manged C++ Extension,也支持/GS做Buffer Overrun Check和其它/RTC选项(Cool Feature!)。在C++ ISO标准兼容方面,Visual C++ 2003已经支持Partial Template Specialization,目前还不支持的(并且似乎也不打算支持的)主要是export keyword——不知道有没有主流的C++编译器(GCC, BC, Intel C++ Compiler)支持这个feature?    And the best of all: It is Free. ...[阅读全文]

posted @ | Feedback (15) | Filed Under [ .NET ]

摘要:  没想过“Under the Hood”还可能有别的比喻。我的想法和展波一样:Hood是前车盖,Hood下面便是汽车的引擎了。  汽车是老美生活中最重要的一部分,大约和我们的自行车差不多,算不上奢侈品。尤其是在中西部,没有汽车可以说是寸步难行。所以也就有了不少和“车”或者“路”相关的谚语,除了上面的“Under the Hood”之外,还有比如“Behind the Wheel”,用来形容亲身实践的经验;Portal Server里面经常提到的“Dashboard”指的是汽车的仪表盘,用在这里再贴切不过了。...[阅读全文]

posted @ | Feedback (1) | Filed Under [ 乱谈 ]

摘要: FACT: 从Java到C#的转换要比从VB到VB.NET容易得多。  自从VB.NET把VB的语法翻的地朝天之后,VB程序员们一直在努力找寻一个问题的答案:“Is VB Dead?”。 Managed C++将会在Visual Studio 2005(Whidbey)中经历一个类似的语法变化过程:所有的__keyword(__gc, __nogc, etc)都会被废除,取而代之的是一些新关键字和语法。下面是从Stanley Lippman(The author of “Inside C++ Object Model”和“C++ Primer”,两本书都有侯捷先生的中译本,著译都很经典)的blog上摘录的一段改变前后的代码: // original language syntax public __gc __sealed __abstract class State { public:       static State();       static String* version();   private:       static String* ms_version; };   // revised language syntax public ref class State abstract sealed { public:       static State();       static String^ version();   private:       static bool ms_inParam; };    新的语法显然更干净整洁一些(除了那个“盖帽”式的引用^),但是如此大规模的语法改动,不得不让人担忧Managed C++会不会重蹈VB.NET的覆辙——倒是不用担心C++的命运,C++程序员(包括我在内)大概是这个地球上最顽固的群体:“一场大灾难之后,这个地球上只剩下蟑螂、老鼠——还有C++程序员。;)”    C++/CLI Syntax Draft Download...[阅读全文]

posted @ | Feedback (12) | Filed Under [ .NET ]

摘要:  WebService本质上是在HTTP或者其他传输协议上传递Xml/Soap消息,只不过.NET Framework通过一些底层支持使它看起来像是一个Object的方法调用(BTW:有人说.NET在WebService上最大的错误就是把WebMethod包装的太像Object方法调用)。  CSDN上有人问如何在WebMethod里直接接收/返回Xml,有人回答说返回String。但是作为String的XML在传输之前会被Encode,'<'会被转换成'&lt;',等等。这样的格式不利于进一步的Schema验证或者interop。正确的做法是在WebMethod里接受/返回XmlElement,.NET Framework能够正确的把这些Xml嵌入对应的SoapBody里面:   [WebMethod]   public XmlElement SayXml(XmlElement param)   {         //...   }  这时候.NET仍然会给传入/传出的Soap消息加上一层包装:  SOAP request:  <soap:Body>    <SayXml xmlns="http://joycode.com/qqchen/webservices/">      <param>xml</param>    </SayXml>  </soap:Body>   SOAP response:   <soap:Body>    <SayXmlResponse xmlns="http://joycode.com/qqchen/webservices/">      <SayXmlResult>xml</SayXmlResult>    </SayXmlResponse>  </soap:Body>   如果我们需要完全控制SoapBody的内容(例如,需要这部分内容符合某个给定的Schema),可以通过SoapDocumentMethod(去掉SayXml和SayXmlResponse)和XmlAnyElement(去掉param和SayXmlResult)两个特性实现,这里是完整的代码和对应的Soap消息模板:  <%@WebService Language="C#" Class="MyServer.MyService" %>   using System.Xml;  using System.Web.Services;  using System.Xml.Serialization;  using System.Web.Services.Protocols;   namespace MyServer  {     [WebService(Namespace="http://joycode.com/qqchen/webservices/")]     public class MyService : System.Web.Services.WebService     {        [WebMethod]        [SoapDocumentMethod(ParameterStyle=SoapParameterStyle.Bare)]        [return: XmlAnyElement]        public XmlElement SayXml([XmlAnyElement]XmlElement param)        {             //...        }     }  } POST /xml.asmx HTTP/1.1 Host: localhost Content-Type: text/xml; charset=utf-8 Content-Length: length SOAPAction: "http://joycode.com/qqchen/webservices/SayXml" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" ......[阅读全文]

posted @ | Feedback (13) | Filed Under [ .NET ]

摘要:      C++和Java/C#在基本设计理念上是不同的:C++倾向于把强大的功能不计后果的推出去,让程序员自己调整适应,结果就是功能最强大,也最容易被误用的语言;Java/C#则相反,无论一个新功能能够带来怎样的性能或者开发效率优势,如果不完全清楚它在安全和易用性上可能造成的后果,那么设计者宁可限制这个功能的使用。最明显的例子是Pointer,最近在和Justin Shen、Lostinet... 讨论的Generics大约也算是。     More: 对C++来说,合格的语法不一定能拼成合格的程序,像virtual destructor,copy constructor这些概念都要程序员正确理解,编译器对此无能为力。所以C++程序员通常更注重所谓Best Practice,C++著作一大半是这方面的:Effective C++, More Effective C++, Effective STL, Exceptional C++等等;C#的编译器替我们take care了太多的问题,需要注意的语法之外的事项少了不只一个数量级,所以目前C#的著作一多半只是语法讲解,有几本例外:Applied .NET Framework Programming, Advanced .NET Remoting... 寥寥几本。    Best Practice可以用来区分高级C#程序员和初级C#程序员;但是没有Best Practice,就没有C++程序员了。...[阅读全文]

posted @ | Feedback (2) | Filed Under [ .NET ]

摘要:The need for Constraints   C++将Generic Programming(泛型编程)的概念发挥得淋漓尽致。作为C++唯一的标准库,STL主要是应用Template,而不是面向对象的继承机制来实现的。很自然的,我们会把CLR和C++的Generic实现进行对比。Constraint是CLR在实现Generic时独有的概念,而且Constraint的使用也确实对CLR Generics在功能和性能方面有些负面影响。So, Why do we need constraints?  CLR和C++在模板实例化采用了不同的策略:C++主要是编译期间实例化模板,也就是说当编译器看到程序中引用了vector<int>的时候,它就会用int代换vector<typename T>中的T,生成一份vector<int>的代码到目标文件,这样做有几个问题:1) 代码冗余。如果在不同的.cpp文件中引用了vector<int>,那么每个编译产生的.obj都会包含vector<int>代码的一个拷贝。Link.exe必须能够正确处理这种特殊情况才能避免代码冗余。2) 由于实例化发生在编译期间,即使vector<int>仅在一个极少被调用的code path上被使用,它的实例化代码也会自始至终占据一块内存。3) 缺乏动态泛型支持(C++本身没有完整地Runtime的类型支持,并且不建议使用RTTI,所以这是和Generic一致的;但是如果向C#/Java这样本身支持Reflection的语言不支持Generics Reflection,就显得有些怪异了)。  CLR选择了在Runtime动态实例化模板。编译器可以在没有泛型参数的情况下编译生成List<T>的扩展MSIL指令;在运行时刻,程序代码中第一次引用List<int>的时候,CLR才动态的使用int类型实例化List<T>,并且生成实例化的代码(实际上只有新的ValueType才会引发模板实例化,ReferenceType共享一个实例化的模板代码),这就解决了上面提到的两个问题。由于CLR完全理解Generic语义,就可以在Reflection当中添加Generic支持,第三个问题也迎刃而解。  但CLR的实现方法也带来了新的问题:如果作为实例化参数的类不能满足Generic Type的要求(这些要求多种多样,可能是具有某个方法,某个操作符重载等等),实例化失败将会导致运行时错误,而不是像C++那样的编译连接错误。我们总是希望在编译期间检查出尽可能多的错误,但是显然不可能让C#编译器逐行检查Generic Type的MSIL指令来判断泛型参数是否符合要求(E.g. 如果Generic Type包含一条MSIL: call 0!.SomeMethod(),那么T必须定义SomeMethod)。折衷的方案是在Generic Type的MetaData里面显式的指明它对泛型参数的要求,这就是Constraint了。所以Constraint实际上是Generic Type对泛型参数要求的MetaData表示,其目的是帮助编译器尽早验证参数的合法性。  So, Constraint By Signature or By Type?   Constraint在实现可以选择两种不同的语义,一是By Signature,C++实际上隐含了这种语义。例如:类型参数T必须定义一个返回bool,接受一个T类型参数的CompareTo函数;或者T必须重载operator+,等等。这种方式的优点很明显--灵活性大,我们可以自由表述对泛型参数的各种要求;它的缺点是需要非常复杂的Constraint语法(C++不需要显式指出Constraint)。另一种方式是By Type,指出泛型参数必须从某个类继承,或者实现某个接口,还是上面的例子,我们可以说T必须实现IComparable<T>这个接口。这是C#/.NET采用的方式,语法上看非常简单,和普通的类继承/接口实现非常相似;但是表达能力就不如By Signature的方法,像operator overload这些不能用接口描述的语义就很难表达了。  Anders Hejlsberg在一篇专访当中谈到过C++和C#(实际上是CLR)在Generic实现上的异同,也分析了By Type Constraint的一些限制。 The Performance Implication of Constraint  采用这种By Type的Constraint的确对Generic的性能有一些负面影响。例如:    1) 由于Constraint必须采用interface,Value Type Object必须先Box,然后调用Constraint方法。如果采用By Signature,这个Box/Unbox操作应该可以避免。    2) 我们分析过interface method call比direct method call 或者virtual method call要慢,采用Interface based Constraint即使对reference type也会造成interface call overhead。  我在去年的MVP Summit上曾经问到过Constraint对Generics Performance的影响。我相信如果在JIT这个层次引入相应的Heuristic,上面的一些性能影响应该是可以被最小化的。当然,无论如何,采用Template + Constraint的List、HashTable始终要比使用Object的版本性能要优越些。...[阅读全文]

posted @ | Feedback (6) | Filed Under [ .NET ]

摘要:  Just read Saucer's blog. Can't agree more!   Something is just not worth it. Joy, back anytime and you will be more than welcome. ...[阅读全文]

posted @ | Feedback (7) | Filed Under [ 乱谈 ]

摘要:在返回纽约的飞机上,我的脑细胞们正在拼命的消化Summit最后一天被填鸭式的塞进来的一大堆东西。 第三天参加的是Indigo,或者叫做WebServices,的产品组讨论。介绍的内容包括了Whidbey Release中System.Net、System.Web.Services和System.Xml.Serialization的新特性、WSE2.0、Indigo和如何从目前的Remoting、ASMX和ES向Indigo移植(我会在接下来的blog中陆续整理这些部分的内容)。但是其中最令我震惊的,是临时增加的Bill Gibson做的关于Whitehorse的Demo。    The message is out: “Microsoft is building model based development tool!” Whitehorse是Microsoft正在开发的针对SODA (Service-Oriented Development Architecture) 的建模工具。说到建模工具,最先想到的无疑是UML,或者更早期的CASE。但是作为OOAD环境下的建模工具,UML缺乏对Service-Oriented System Modeling过程所需要的一些概念的支持,例如Service Schema & Contract、Data Center以及Policy。另一方面,目前的建模工具在系统一致性方面都存在一定的缺陷,开发人员经常需要通过手工编辑来维持源代码和系统模型之间的一致性(比如,如果在自动生成的源代码中添加或者删除一个方法,改变一个参数,往往必须手工在系统模型中完成相应的动作才能保持两者一致),复杂的操作往往导致开发人员最终放弃系统模型或者仅仅用它来作为代码的一个非高度一致的文档。系统模型在应用部署和维护工程中的作用也非常有限。 Whitehorse Project的主要目标就是为面向服务的系统开发提供一个方便高效的建模工具。作为面向SOA的建模工具,Whitehorse直接支持Service Schema、Contract等等概念,并且能够通过用户建立的模型自动生成WSDL、Policy文件以及C#/VB.NET源代码。另一方面,从目前的Demo来看,Whitehorse具有惊人的反向工程能力,能够自动保持C#/VB.NET源文件和系统模型的高度一致。这两个特点使得Whitehorse极大超越“文档工具”的范畴,成为和开发语言/平台同等重要的系统开发工具。 和UML类似,Whitehorse仍然采用多视图模式,每个试图采用图形化的定制建模语言。在概念级别视图上支持Business Entity(例如客户和订单)和Business Process(例如Place Order);在系统逻辑层上支持Web Services试图和系统逻辑试图(系统的部署和配置)。一方面,这些试图所表达的信息被完整的转换和映射到具体的实现程序语言(C#/VB.NET)和网络拓扑结构上;另一方面,程序语言和网络拓扑信息也被反馈到系统上层,用于检查将来系统部署和维护中可能出现的问题。此外,Whitehorse将会具有良好的可扩展性,通过使用Whitehorse提供的基础结构,你可以定义自己应用于某个特定领域的建模语言(DSL,Domain Specific Language)。 Whitehorse的一个部分(3 Designers, maybe the class designer、service designer and ???)将会和Whidbey一起发行。作为Microsoft Distributed Systems Initiative的一个部分,微软对Whitehorse给予厚望。Bill Gates在接受eWeek的采访时就曾特别提到Whitehorse:   “Modeling is the future…Web services forces you to think modeling. And that's part of the good thing about it… ”   Some screen shots of whitehorse: 1, 2, 3...[阅读全文]

posted @ | Feedback (12) | Filed Under [ .NET ]

摘要:  最近看到很多关于Generics和Boxing性能的讨论,大家对这两部分的性能都非常关心。其实这两个部分最终的性能表现往往会通过Method Call等等比较底层的CLR功能反映出来,如果没有对底层构造的深入了解,可能会导致新能分析的一些误差。     .NET CLR通过Call和Callvirt两条指令支持三种方法调用模式(另一条MSIL指令Calli和这里讨论的内容关系不大): l         直接方法调用(Direct Method Call): 这是最简单的方法调用模式,如果C#/VB.NET编译器可以静态的解析需要调用的函数,那么编译器就直接生成Call指令,并且把目标函数的地址(实际上是一个引用标志,理解成函数地址要容易一些)直接放在MSIL指令当中。在运行时CLR也不需要进一步解析,直接调用这个引用的函数就是。例如:     call   instance void SomeType:: SomeMethod()   NOTE: 有时候Compiler会生成Callvirt指令来进行直接方法调用,这时候主要目的是利用Callvirt指令的一个附带作用:当this为null的时候,它会throw exception;而Call不会。但是底层JIT生成的机器指令仍然是一条直接方法调用指令。   l         虚方法调用(Virtual Method Call): 这种方法和C++的vptr/vtable机制类似。由于subclass和override,编译器显然无法在编译期间识别出运行时需要调用的具体函数。所以编译器生成Callvirt指令,加上父类对应方法的引用。在运行时刻,每个Reference Type Object和Boxed ValueType Object都有一个指向其类型信息(MethodTable)的指针,MethodTable包含了这个类定义的所有方法(可能还会有重复),并且它的函数表前部顺序保证和父类MethodTable相同。这样CLR通过Object找到对应的MethodTable,然后从MethodTable中找到与指令中引用的方法对应位置的函数入口,然后调用该方法。     callvirt   instance bool Object::Equels(Object o)   l         接口方法调用(Interface Method Call): 这是.NET独有的调用方式。由于仅支持单继承,MethodTable格式上只要与自己的父类一致。但是接口实现的时候仍然可能出现C++经常提到的钻石结构或者命名冲突。.NET的解决办法是引入Interface Map:编译器产生的代码和前面的Virtual Method Call完全一致,只是引用的方法是Interface的而不是父类的;在运行时刻MethodTable当中包含了一个InterfaceMap的指针,通过InterfaceMap,CLR可以找到MethodTable结构中和某个Interface结构顺序等价的一个段落,从而找到并且调用相应的接口函数。     callvirt  instance bool IComparable::CompareTo(object o)   下图表示了这三种方法调用的路径。显然,直接调用通过JIT生成的机器指令最少,只需要一条x86 Call汇编指令,虚方法调用和C++的vptr调用类似,需要两条机器指令,包含一个间接调用;接口调用最慢,大约需要4条机器指令,包括间接调用。       接下来需要做的就是正确识别出在什么情况下编译器会选择哪种调用方式,例如下面代码中的方法调用,不妨尝试分析一下。J   interface ITest {        void SomeMethod(); }   class TestClass : ITest {        public virtual void SomeMethod2() {               //…     }          public void SomeMethod() {               //…     } }   //… ITest itest = …; TestClass tobj = …;   itest.SomeMethod();      //? tobj.SomeMethod();       //? tobj.SomeMethod2();     //? ((TestClass)itest).SomeMethod();  //?...[阅读全文]

posted @ | Feedback (14) | Filed Under [ .NET ]

摘要:   “No one can be told what the Matrix is. You have to see it for yourself”                                          ----- Suprisingly, Bill Gates.  终于如愿以偿看到了Bill Gates和Steve Ballmer的Matrix,Bill是如何Free “Steval”'s mind。 难以置信,Microsoft真的请了Wachowski兄弟帮助制作这个短片!  Steve Ballmer个人魅力十足,他的演讲坦诚而且富有激情。这主要是一个Q&A Session,谈到包括Office VBA等等问题(BTW: According to him, VBA support will be there in next windows release)。有这样一个问题:Does Microsoft treat Open Source as a threat?  Steve地回答是,Open Source不是Microsoft的Threat,而是Competitor。“Threat is something you are afraid of, while competitor is not”。Steve坦言和Linux的竞争是不可能通过价格战取胜的,而只能是“Build Better Product”。就Client应用而言,Windows目前的优势是:    1) TCO: 对个人用户而言,Windows的TCO(Total Cost of Ownership)大约仅比Linux高$50。    2) Support & Application:Windows平台拥有更多的应用程序,拥有更直接的技术支持。    3) Legal Protection: Microsoft为Windows系统承担所有知识产权相关的法律责任,但是没有人为Linux用户但当相应的角色。也就是说,Linux的用户需要直接承担Linux的法律责任。(一个相关的案例,SCO sues Linux)   但是在Server平台上竞争更加激烈。就安全性而言,Windows的市场占有率决定了即使它和Linux具有近似的安全特性,Windows也会受到更多的exposure和complain,Microsoft对此的回应是集中精力增强Windows的安全性,争取将竞争对手远远抛在脑后。这就回到了从XP SP2到Longhorn将会出现的一系列增强的安全新特性...   ...[阅读全文]

posted @ | Feedback (6) | Filed Under [ .NET ]

摘要:      “For those who haven't (installed SP2), Shame on you!”                                --- Don Box, MVP Summit Day 1     Jim Allchin的Demo主要是针对SP2的安全特性,SP2引进了许多新的安全控制,包括IE Pop-up Blocking,Auto ActiveX Download Blocking(Remember 3721? Won't happen any more!!!!)、Windows Firewall等等。     我印象特别深刻的是两个特点:当我们在公共场合使用Wireless Internet的时候,总是希望尽可能的减少网络资源的共享,现在唯一的办法就是逐个修改设置:Shared Folders,IIS,等等等等,SP2的一个新的选项就可以一步把你的计算机设到这种隔离模式,并且可以简单的恢复;第二个是关于Outlook Express的下载文件运行控制,除了Block带可执行文件的附件(包括在zip文件内的EXE)以外,即使是把这个文件Sava As到硬盘上,Windows系统仍然会缺省限制该程序的运行!SP2 RC1可以在MS网站下载。    Jim在Demo Pop-up blocking的时候用了Britney Speares的主页: “Britney has a lot pop-ups... If we turn off the pop-up blocking option, those would actually ...(满场狂笑,Jim终于没有把句子说完)”。    后面还有一些非常COOL的Demo,但是.... 不可说,不可说,呵呵。...[阅读全文]

posted @ | Feedback (2) | Filed Under [ .NET ]

摘要:  昨天偷懒了,今天补课。 第一天比较有趣的Session是Don Box和Chris Anderson一起Host的“Talk Show“ Longhorn:Avalon & Indigo。Demo主要是针对Avalon的——一个在屏幕上旋转的带Button的菜单,完全用XAML编写,没有一行C#/VB.NET Code。还有一个是关于3D桌面的。UI不是我的强项,就不多提了。我主要关心的是关于Indigo的一些内容,Don的Session没有关于Indigo的介绍(PDC的内容已经足够了),主要是Q&A: Q: Indigo的发行方式和发行时间? A: Longhorn会包含一个完整的Indigo。另外支持Windows XP/Server 2003的Indigo可以单独下载(Windows 2000不在支持之列)。Indigo目前仍然是开发初期,具体发布时间不确定。但是可以肯定会在Whidbey之后,Longhorn之前,因为Indigo需要使用Whidbey的一些特性,但对Longhorn没有特别的依赖。 Q: Indigo的系统兼容性。 A: PDC发布的Preview版本对ASMX/Remoting的兼容性还很差。但最终Indigo的目标是完全兼容目前的ASMX,包括其他厂商的WebServices。与SOAP Remoing兼容的需求相对较低。(我个人的理解是: SOAP Remoting使用的RPC/Encoded Style SOAP已经在新的SOAP 1.2当中被逐步废除,Indigo当中几乎没有支持这种模式的必要性。猜想而已,不确定)。 Q: 怎样从目前的ASMX、Remoting和Enterprise Services向Indigo移植? A: ASMX的移植最简单,简单的改变源代码的Namespace就行了。但是在ASMX中最好不要使用HTTP Context相关的内容,Indigo是传输协议中立的,使用HTTP Context会给移植带来不少麻烦。Remoting和Enterprise Services的移植会相对麻烦些,需要修改源代码的一些内容。今后可能会有一些辅助工具,但目前最好的工具是:(Don的原话: Go to your bath room, look into the big mirror, and you will see it!) Q: Indigo对DTC/Transaction的支持? A: 从Whidbey到Longhorn的一系列Release会在Transaction的使用上有重大突破,这些Release会“Rock the Transaction world!”。(从PDC的内容来看,除了DTC以外,Whidbey将会包含一个Lightweight Transaction Manager,把Transaction的概念引入数据库以外的程序中来,和Exception体制结合,加强程序的自恢复能力;Longhorn则会包含一个Kernal Transaction Manager,形成从LTM到KTM到DTC的三层模式,达到性能和功能的平衡)。 Don的一段VB.NET(Don称之为God's Language,明白是什么意思?)程序很酷:Public Class Class1       Public Sub SomeMethod                MessageBox.Show(“Hello, World“)  ';      End SubEnd Class...[阅读全文]

posted @ | Feedback (1) | Filed Under [ .NET ]

摘要:4月3日 4:00AM   坐地铁赶哥伦比亚大学早上6点到华盛顿特区参观樱花节的专车。 4月3日 11:30AM 到达华盛顿特区,参观了Capital Hill、林肯纪念堂、华盛顿纪念碑... 当然主要是看樱花了(National Cherry Blossom Festival)。 4月3日 6:00PM  原车开始返回纽约,单程需要5个小时。 4月4日 12:00AM 回到新泽西家中。整理出一些照片。 4月4日 1:59 AM 美国切换回夏令时,直接跳到3:00AM。 4月4日 3:30AM从家里出发,感到JFK机场乘坐7AM到西雅图的飞机。 4月4日10:00AM(太平洋时间)历经6个小时的航程,到达西雅图。在Hotel见到Grace、Saucer和唐一均。 前后近40个小时没有合眼,并且最后到达西雅图,史称Sleepless in Seattle。 :)  ...[阅读全文]

posted @ | Feedback (7) | Filed Under [ 乱谈 ]