用户体验!=挑剔的美工设计

Categories: 未分类
Tags: No Tags
Comments: 2 Comments
Published on: 2010 年 07 月 12 日

最近一年来,国内互联网业界突然流行起来“UX用户体验”风。这一方面得益于Apple等巨头在这方面极致的表现,另一方面现在信息过载导致用户越来越挑剔,从而对体验越来越重视了。《程序员》甚至为此出了专题:《刘江: 用户体验,技术人员的必备常识》

但是许多UX的强调者,很容易偏向“界面设计”,甚至将UX理解为“挑剔的美工设计”。其实用户体验的核心应该紧紧围绕“价值和用户”两个基本点

1. 价值,决定了互联网产品到底向用户提供什么样的核心功能?——说的通俗一点,满足了用户什么样的核心需求?

2. 用户,决定了互联网产品为什么样的用户提供服务?——说的通俗一点,你定位的用户是哪一群人?他们有什么样的特征?品味?偏好?习惯?

理清了“价值和用户”,UX就上到正道上了,至于美工设计是其后的事情。比如hao123,在专业美工眼里,比较差(如果不是很差的话),但是它的用户体验确实很好的。其根源就在于它围绕自己的核心价值:上网导航;和用户定位:记不住网址的大众用户。再比如Apple,绝对不是靠令人震惊的UI而成就伟大产品的,Apple首先理清了“如何利用互联网来提供音乐服务(iTunes)、PDA服务(iPhone)、居家上网服务(iPad)……以及它们的核心客户群,这些缔造了伟大产品的基础。也奠定了极致UX的基础。

而“价值和用户”实际上是一个互联网产品的灵魂,或者战略核心,而这往往只有创始人来推动才能奏效。所以目前许多成功的用户体验都是由创始人亲自抓的。

如果理不清核心“价值和用户”,单纯将UX理解为UI,往往会走偏(能走正确是瞎猫碰到死耗子),不管是“极简主义”,还是“炫技派”,再漂亮、专业、符合审美的UI,在用户眼里也是花拳绣腿,甚至南辕北辙。

Metadata是.NET平台的核心灵魂

Categories: 未分类
Tags: No Tags
Comments: 8 Comments
Published on: 2010 年 07 月 12 日

网友来信:李老师,您好!前几天在博客园上的C#大论战,不知道您看过吗?特别是其中一个网友firelong所写的几篇轰动的帖子,对.NET的性能提出了许多批评。这个话题在我们项目组也引起了很多争论,很想听听李老师对这些观点的看法?……….

本来是以email的形式回复这位朋友的,但是写着写着发现写得长了,最后考虑将其以博文的形式登出。

其实个人无意参与这样的论战,因为很多口水帖、情绪贴. 我简单浏览了一下,发现论战的各方(firelongjeffreyzhao,以及.NET社区众网友),最后都情绪激动了,情绪激动之下讲的话大多都丢失了技术最扎实、最基本的原理。但是这些文章在口水之外,确实有一些深层次的技术问题暴露出来——有些甚至跨越.NET,而延伸到更广泛的领域。但是,它们却被口水淹没了,没有好好深入讨论下去,非常可惜。这便是我最后决定写这篇文章的原因。我希望能够对其中被忽视的一些技术问题,做一些有意义的探讨,与大家共享。

首先我想就《C#会重蹈覆辙吗?系列之2:反射及元数据的性能问题》一文中的主要技术点来谈谈。这篇文章主要观点如下(并且给了相应的分析):
1. 使用反射会有很高的性能成本
2. 即使不用反射,为支持反射而产生的metadata也有很高的性能成本

因此,作者才得出来在《C与C++社区混战,C#会重蹈覆辙吗?》一文中“删除反射”的结论。关于反射和metadata带来的性能问题,我想没有人会否认,只是其性能问题到底有多糟?我后面有空的话也许会另文讨论(firelong文章中有部分含糊其辞)。

本文中,我想讨论的是《C#会重蹈覆辙吗?系列之2:反射及元数据的性能问题》一文的整个推理过程中的一个基本论点:.NET平台中metadata的目的是为了支持反射

在这个论点的基础上,文中才有“反射并不常用,为了支持反射所创建的metadata却带来很多性能问题。因此删除反射,也就不需要创建metadata,这样.NET就不会为此再付出性能损失(就像C、C++那样)”。

很不幸,这个基本论点是对.NET平台的极大误解。换言之,在.NET平台中metadata的存在绝对不仅仅只是支持反射。实际上,支持反射只是metadata一个很小的用武之地,metadata是整个.NET平台非常核心的基础支撑设施,它在.NET平台中有着广泛的应用,是.NET平台的灵魂。

为什么这么讲?这要从.NET创建时的整个软件时代背景来谈起,我们才能深刻理解这一点。.NET创建之前,Windows平台的软件技术经历了以下几个阶段:DDE、OLE、ActiveX/COM。这些技术所努力解决的核心目标是:软件组件的复用性——这是软件开发的核心命题,是软件平台厂商竞逐的焦点。“软件组件的复用性”有以下几个含义:

1. 强调二进制级的复用(黑盒复用),而不是源代码级的复用(白盒复用)。
例如:我想在我的软件中集成PDF阅读器的能力,我不需要找Adobe要PDF阅读器的源代码,而是去找Adobe要一个支持PDF阅读的二进制组件——然后通过接口的方式来使用它。
2. 强调多语言创建的组件之间的复用,而不是单一语言创建的组件之间的复用。
例如:我在C++中写一个Email收发组件,可以在VB中直接使用。

DDE、OLE、ActiveX/COM无一不是围绕这个目标。COM是这些技术发展进程中的一个高峰。但是COM技术本身在发展过程中暴露出了很多问题。Don Box在《Essential .NET》一书的第一章“The CLR as a Better COM”对COM的问题有非常深刻的解剖。

首先,要达致“组件复用”这一目标,必须有合同来规范组件与执行环境、组件与组件之间的各种约定。COM使用的是IDL或TLB作为组件合同,但它们有几个根深蒂固的缺点:

1. IDL/TLB规范的是物理语义(例如v-table偏移,栈帧,参数,数据结构,对齐等内存细节),且使用的是C++语言的一个子集约定。
2. IDL/TLB规范描述与组件代码本身分离。
3. IDL/TLB规范较为混乱,没有达成业界统一的标准(第三方难以扩展开发)

其中第3点问题是微软对COM没有前后一致的系统规划导致——这一点如果假以时日是可以解决的。但是前面1、2点的问题是COM根深蒂固的问题,导致了COM组件后期出现的各种难以解决的问题——不同语言实现面向COM的编译很难,因为满足了COM的复用模型,往往要打破该语言本身模型所约定的复用。同时在一个语言中维护两套编译模型、和复用机制,步履维艰(在C++、VB、Delphi等语言中开发COM组件的痛苦相信很多人深有体会)。

而这个时候,95-98年间名声大噪的Java给了微软相当大的启发。特别是其中的metadata,微软的技术精英发现metadata是最好的组件合同定义体。Metadata有以下几个非常好的特点(这些正好克服了COM组件描述IDL/TLB的缺点):

1. Metadata描述的是逻辑结构,不涉及任何物理细节(例如v-table偏移,栈帧,参数,数据结构,对齐,方法地址等物理细节,直到在具体平台上加载、执行时,才被确定,比如IL代码中经常看到的CALL指令后面的 MyClass:MyMethod就是逻辑上的元数据,而不是具体方法的物理地址)
2. Metadata本身与组件代码合并在一个文件中(即程序集),包含了组件依赖,版本等信息
3. Metadata从一开始就经过系统、精心的设计,是CLI业界标准的一部分(便于第三方开发相关应用)

这些特点使得metadata非常适合作为.NET组件与执行环境(CLR)、组件与组件之间(不用语言开发的组件)理想的合同规范。特别是第1点,“Metadata虚拟的逻辑属性”使得组件合同专注于“逻辑语义层面”,而非“物理实现细节”。简单解释一下:
1. 组件与组件的复用从此集中于“逻辑语义层面”,比如C1的方法M1中调用MyClass的方法MyMethod,用语义表达为:call MyClass:MyMethod。或者C1类继承C2类:用语义表达为:class C1 extends C2。或者调用虚方法:callvirt MyClass:VirtualMethod….
2. 组件与组件的复用不再纠缠于“物理实现细节”,例如:调用某个方法,必须知道它的入口点地址如jmp 0×000688;继承某个类,必须清楚它的字段layout等等,调用虚方法,必须清楚v-table偏移规定…..

那为什么“专注于逻辑语义层面的合同”要优于“专注于物理实现细节的合同”呢?

这就又要回到前面说的“软件组件的复用性”这一目标上来。简单来说,如果要实现“软件组件的复用性(注意二进制、多语言两个属性)”,“专注于物理实现细节”对于各个语言的编译器厂商,要求太高了,各编译器厂商要协调一个执行体各个方面的物理细节(v-table偏移,栈帧,参数,数据结构,对齐,方法地址等等…..不一而足)——这么多细节的要求,使得大家极难协调——COM后期的弊端丛生就源于此。

而“专注于逻辑语义层面
”来实现组件的复用性,各编译器厂商生成的执行体(即.NET里面的程序集)只需要“用metadata表达逻辑语义上的复用规范”即可——这对于各编译器厂商需要协调的规范的量级大大减少,实现起来相对容易得多。也不容易在各种细节上出现漏洞——因为大量的物理细节全由CLR执行时来确定。

综上所述,metadata的根本性的作用是支持“基于逻辑语义的组件复用”——这是.NET致力于打造软件开发平台的核心目标。支持反射仅仅是metadata一个很小的衍生功能,而非主要功能。

事实上除了支持“基于逻辑语义的组件复用”这一核心目标外,metadata在.NET平台中还起着其他重要作用(有些是组件复用的延伸需求,比如JIT与跨平台):

1. Metadata是JIT编译、亦即实现.NET跨平台的基础
说明:IL代码中大量引用着Metadata。在MethodDef元数据表里面存储着一个方法的各种语义信息,许多IL指令就直接内嵌了Metadata Tokens。没有Metadata,JIT也无法实现。

2. Metadata是.NET支持垃圾收集GC的基础
说明:metadata标记了对象与对象间的引用关系,这是GC遍历对象图(判断对象是否可以收集)的关键依据。没有metadata,GC将不知道0×000688是一个指针(需要继续遍历)?还是一个整数(不需要继续遍历)?

3. Metadata是描述类型契约、标识、规范等的基本信息
说明:强命名程序集(使用metadata描述)唯一标识了编译器当初编译时的组件,不至于导致运行期仿冒、或者版本偷换(即DLL 地狱问题)

4. Metadata是.NET管理组件安全的基础(运行时类型检查,组件下载)
说明:metadata会告诉CLR执行环境一个组件的安全边界,从而可以管理那些恶意代码。

5. Metadata是.NET管理组件引用关系,加载的基础
说明:metadata会告诉一个组件需要引用哪些组件(哪些版本)?这是组件加载的基础。

从这里大家可以看出来,Metadata是.NET平台实实在在的基石。Metadata之于.NET平台,就像维他命至于生物体一样。换言之,删除反射,并不能消除metadata。如果要消除metadata,.NET平台的整个设计基础(组件复用,以及上述的其他种种功能)将不复存在。

最后,指出《C#会重蹈覆辙吗?系列之2:反射及元数据的性能问题》一文中的核心论据错误,并非为了追求驳倒firelong。建议firelong,jeffreyzhao以及这场辩论的众多技术领域的网友(不管是firelong,jeffreyzhao支持者还是反对者),抛掉“非要辩个胜负,分个高低”的怪诞氛围,而是来一些扎扎实实的技术说理过程,相信会更有意义——如是,则国内技术社区成长可待!

重新开博, 技术观察

Categories: 未分类
Tags:
Comments: 6 Comments
Published on: 2010 年 07 月 12 日

由于近几年经营公司,创业路上在黑暗中摸索,常常需要“扶大厦之将倾”,无暇顾及博客,我于2005年底结束了joycode的博客写作,谢谢开心的理解。

在经过几年的探索后,战略终于得以聚焦,目前进入创业的稳定成长期。有了更多闲功夫和侃大山的冲动:)  于是决定在joycode重新开博,也算是以功谢罪(看着joycode上几乎荒芜的blog甚是歉疚)。

我目前正带领一个.NET技术团队在开发一个互联网社区网站。今后会在这里和大家分享一些有关.NET技术、互联网等各方面的心得。

我同时还在这里http://techvery.com/jzli/维护有一个更私人化的blog,上面除了技术话题外,还会有更多与创业运营、团队管理、行业观察等乱七八糟的杂谈记录。另外在新浪,还有一个更碎片化的微博:http://t.sina.com.cn/jzli。在JoyCode上的blog会集中在纯技术方面。大家可以根据不同的兴趣来订阅。我会同时在这几个地方回复。欢迎新老朋友交流。 

 

Learning C++/CLI as a New Language

Categories: 未分类
Tags:
Comments: 13 Comments
Published on: 2005 年 09 月 23 日

由于Stan Lippman的突然缺席(不过各位不必太过遗憾,Lippman会在年内来中国弥补 http://blog.dreambrook.com/jzli/archive/2005/09/20/1196.aspx),北京九华Tech Ed上有关VC++ 2005的Session 只有我这一场了,战战兢兢,如履薄冰。

 

我的Session: Visual C++ 2005 : 无缝集成,无限潜力

9月25日下午14:45–15:45

课程编号:DEV 349

我将在此次讲座里谈谈如何使用VC++ 2005的几种集成技术来无缝地桥接managed world和unmanaged world。然而1个小时(还包括10分钟的Q&A)的演讲确实太短,ppt本来我是制作了很长的,但是不得不忍痛割爱了。不过如果时间允许的话,我还是希望略微谈谈“使用C++/CLI来迁移ISO-C++下的Application Framework”这样的大话题。

 

BTW,刚刚从Herb Sutter的blog http://pluralsight.com/blogs/hsutter/archive/2005/09/22/14970.aspx得知C++/CLI Standard已经接近被ECMA批准,那些认为C++/CLI昙花一现的言论不攻自破。

So, Learning C++/CLI as a New Language! 不知博客堂的各位看官有几位会有耐心来捧场?

 

 

Under The Hood in .NET——使用C++/CLI实现托管版的sizeof (引言)

Categories: 未分类
Tags:
Comments: 12 Comments
Published on: 2005 年 07 月 01 日

最近在讲授C#培训课程中谈到托管对象内存的布局(Layout)和托管对象大小的问题时,一位学员问了这样一个问题 “既然每一个对象都是有大小的,为什么C#语言没有提供sizeof操作符?”

 

当然这个问题准确的问法应该是“为什么C#语言的sizeof操作符不能应用于class上?”,因为实际上C#是提供有sizeof操作符的,只不过只能在unsafe代码中对struct类型使用。而更进一步的问题便是“如何获取托管对象的大小?”

 

 

这个问题表面看起来并不大,但是仔细思考起来却很有意思,如果真的深究下去,恐怕需要把.NET挖个底朝天。正好我在SSCLIShared Source Common Language Infrastructure)上有过一段研究心得,于是便打算写一组文章来探讨这个问题,希望能够满足那些喜欢 Under The Hood”的朋友的胃口。

 

有关“Under The Hood”的解释,可以参见孙展波先生这里的一篇bloghttp://blog.joycode.com/zhanbos/archive/2004/06/10/24208.aspx.当然也可以到这里http://blogs.msdn.com/matt_pietrek/ 寻找“Under The Hood”的创始人Matt Pietrek

 

 

在回答这些问题之前,首先要谈谈“既然每一个对象都是有大小的”这句话,因为我发现并不是每一个程序员对此都有非常清晰的理解。C++程序员一般对此有比较好的观念,但是很多C#程序员、VB.NET程序员,Java程序员对这样的观念很淡薄,甚至许多“搞了很长时间面向对象”的程序员压根就不知道对象还有所谓大小这回事,这也是我在讲授C#/VB.NET培训课程时要着力强调它的原因。

 

因为要搞清楚对象的大小,必须搞清楚对象的Layout。而只有对对象的Layout非常清楚,才能彻底理清栈、托管堆、值类型、引用类型、参数传递,虚方法调用(多态)、垃圾收集。。。。等等这些编程中的核心问题。我以前在面试C#/.NET开发人员时,就把“一个class中定义有一个int、一个byte、和一个string,那么这个class的实例对象有多大”这样的问题作为对一个.NET程序员的“终极测试题”——如果这个问题回答得令人满意,基本上再问其他问题都显得多余。我甚至偏执地认为,只有“清楚了解对象Layout的程序员”才是“真正懂面向对象的程序员”。

 

言归正传,现在开始具体谈谈如何来获取一个托管对象的大小——注意这里说的是“一个托管对象的大小”而不是“一个类型的大小”,后面我会解释为什么要这样说。在这之前,先来看看C#C++/CLI目前的sizeof操作符在值类型上的行为,它对后面探讨托管对象的sizeof多少有一点帮助。

 

 

 C#C++/CLI中的sizeof操作符

 

C#C++/CLI都提供了sizeof操作符,比如在C++/CLIC#不支持在一个含有引用类型字段的值类型上使用sizeof操作符)中,我们可以这样来计算一个值类型的大小:

 

value struct MyValue ...{ Byte data1; int data2; String^ data3; Byte data4; }; int main() ...{ int size=sizeof(MyValue); Console::WriteLine(size); }

 

这里的输出结果为12,单位为bytes。和ISO-C++class的结果不同。其原因为CLR对值类型的Layout做了优化调整,事实上对于上面的声明顺序,CLR在内存中调整如下:

 

value struct MyValue ...{ String^ data3; // 4bytes 指针 int data2; // 4bytes 整数 Byte data1; //1byte 整数 Byte data4;   //1byte 整数 };

由于alignment的作用,最后两个Byte字段后面要再填充两个bytes的空间,因此结果为4+4+1+1+2=12——这种做法显然是比较优化的算法,能够最大程度地节省一个栈对象的内存开销(ISO-C++按字段声明顺序来排列Layout,结果为16)。

 

顺便提一句,从编译出的元数据来看,编译器自动在MyValue上应用了如下Attribute

[StructLayout(LayoutKind::Sequential)]   // 顺序排列Layout

 

但是CLR并没有理会这一Attribute,而是自我主张使用了如下Attribute

[StructLayout(LayoutKind:: Auto)]     // 自动排列Layout,优化方案

 

 

不过sizeof只能在值类型上使用,而不能在引用类型上使用,计算的也是这些值类型在栈上分配的“裸对象”的成本——而非box到托管堆上的多态对象。

 

 

C#C++/CLI不允许在托管类型上使用sizeof,并不代表托管对象没有大小。那么,托管对象的大小如何计算呢?

 

 

预知详情,下回分解:)

 

C++/CLI的“值类型的强类型装箱实例”

Categories: 未分类
Tags:
Comments: 13 Comments
Published on: 2005 年 05 月 12 日

近来接到几个朋友问Visual C++ 2005 (C++/CLI) Webcast中讲的“值类型的强类型装箱实例”是什么?

讲座比较匆忙,因此对这个技术点只是点了一下,没有详细展开。这里借blog把它展开说一下。

首先来看下面的C#代码:

using System; using System.Collections; struct MyClass ...{ public int data; } class Test ...{ public static void Main() ...{ MyClass myClass1 = new MyClass(); MyClass myClass2=new MyClass(); ArrayList list=new ArrayList(); list.Add(myClass1); list.Add(myClass2); Print(list); for(int i=0;i<list.Count;i++) ...{ MyClass temp=(MyClass)list[i]; temp.data=i+1; list[i]=temp;// 注意这句话 } Print(list); } public static void Print(ArrayList list) ...{ for(int i=0;i<list.Count;i++) ...{ MyClass temp=(MyClass)list[i]; Console.WriteLine(temp.data); } } }

其中list[i]=temp这句话很重要,否则无法实施改变,因为temp是一个“和list中hold的boxed的值实例无关的”stack上的实例。

但是如果使用C++/CLI,我们就可以这么做:

using namespace System; using namespace System::Collections; value class MyClass ...{ public: int data; }; void Print(ArrayList^ list); int main() ...{ MyClass^ hMyClass1 = gcnew MyClass; MyClass^ hMyClass2 = gcnew MyClass; ArrayList^ list=gcnew ArrayList(); list->Add(hMyClass1); list->Add(hMyClass2); Print(list); for(int i=0;i<list->Count;i++) ...{ MyClass^ temp=(MyClass^)list[i]; temp->data=i+1; // 注意这里无需再有list[i]=temp这句话,因为temp引用的就是“list中hold的boxed的值实例” } Print(list); } void Print(ArrayList^ list) ...{ for(int i=0;i<list->Count;i++) ...{ MyClass^ temp=(MyClass^)list[i]; Console::WriteLine(temp->data); } }

其实在C#中,我们使用MyClass temp=(MyClass)list[i]; 中间就发生了一个unbox和一个copy动作。

而在C++/CLI中,我们使用MyClass^ temp=(MyClass^)list[i]; 中间只发生了unbox,而没有发生copy动作——注意只发生unbox,而数据还位于managed heap中,但是类型却是MyClass^,这样我们就可以直接获取MyClass的data成员——这就是我所说的“值类型的强类型装箱实例”。

这在C#中是不能做到的,只能获得类型为Object的一个“弱类型”——有一种办法是采用interface来间接实现,因为interface是一个引用类型。

 

“值类型的强类型装箱实例”当然不仅仅意味着“少写代码”,实际上它带来很好的性能提升——因为unbox代价很小,与copy动作是分离的。不像box,它是代价比较高的操作,因为本身包含copy动作。

其实C++/CLI对类型的强大描述能力不仅仅体现在这一个地方,还有很多,比如interior_ptr,这将是我今后将要剖析C++/CLI的一个重点, 也是我去年撰写“漫谈C++/CLI中的几种指针和引用(1)”(http://blog.dreambrook.com/jzli/archive/2004/11/20/352.aspx)系列的规划——可惜后来由于太忙,没有集中的时间展开。展开讨论它要相当大的篇幅,因为它牵扯到对托管对象模型的深入剖析。下面我会随着自己对Shared Source CLI (Rotor)源代码的剖析,来展开这一系列的blog。

《Effective C#》 翻译笔记(1)使用属性,避免将数据成员直接暴露给外界

Categories: 未分类
Tags:
Comments: 23 Comments
Published on: 2005 年 05 月 08 日

Item 1 – Always Use Properties Instead of Accessible Data Members.

 

最近在翻译Bill Wagner先生的《Effective C#》一书,由于自己早先也有Effective.NET写作的打算,所以对书中很多items,也有很多自己的思考。如果作为译注来添加,担心把最后的译本添得四不象,不添又甚感遗憾。正好有blog和论坛,遂考虑把翻译过程中自己的所思所想直接记录下来,供大家讨论打磨,弥补作/译者认识不足的地方,相信也许可以收到正常出版渠道不能取得之效果。blog好像本来就含有“个人出版”之意。言归正传,今天讨论第一个Item。

学习研究.NET的早期,经常碰到一些学习C#/.NET的朋友问,要属性这种华而不实的东西做什么?后来做项目时也时常接到team里的人的抱怨,

为什么不直接放一个public字段?

class Card
{
   public string Name;
}

而非要做一个private字段+public属性?
class Card
{
   private string name;

   public string Name
   {
      get { return this.name;}
      set { this.name=value;}
   }

}

我记得早期的一个项目里,team中的一个朋友甚至厌烦了写private字段+public属性,尤其是碰到一大堆臃肿的data object class的时候,索性自己写了一个小工具,来提供一个类的字段名和类型,然后自动为该类生成相应的private字段+public属性。

我在编程的时候是个彻底的实用主义者,用稍微高雅一点的话说叫“不喜欢过度的设计”。如果真的象上面那样写Card,而且在将来没有什么改变的需求,我也不喜欢后面那样把事情故意搞得复杂。但如果从component的角度来讲,总有一些class是要供外部长久地使用,也潜在地有改变的需求。这时候,提供属性就很有必要了。

这就是这个item试图要归纳的使用属性的理由:

1。可以对赋值做校验、或者额外的处理。
2。可以做线程同步。
3。可以使用虚属性、或者抽象属性。
4。可以将属性置于interface中
5。可以提供get-only或者set-only版本;甚至可以给读、写以不同的访问权限(C# 2.0支持)

个人感觉3、4条是属性最大的优点,可以填补没有“虚字段”或“抽象字段”的缺憾,在设计组件的时候非常有用,也体现了C#这样的component-oriented语言的精神内涵。

但如果没有上述理由,日后也并不太可能做大的改动,我想也大可不必非要把每个public字段都要变成属性。比如在设计一些轻型的struct,用于互操作的时候,直接使用public字段没什么不好。所以,感觉本条目Bill Wagner先生使用“Always Use Properties Instead of Accessible Data Members”显得太过强硬。

 

其实,这里的讨论也表明阅读Effective C#一书时需要注意的地方,即Effective原则并不是防之四海皆准的。不同的项目(组件化、复用程度较高的项目? 还是“一次编写、n年都run”的项目),不同的角色(类库/组件开发人员? 还是应用程序开发人员?),有着不同的Effective准则。 事实上,书中很多items都是从类库/组件开发人员的角度来考虑的。

VC++ 2005 (C++/CLI) 系列Web讲座

Categories: 未分类
Tags:
Comments: 20 Comments
Published on: 2005 年 04 月 19 日

下面几个月我会在MSDN中国的WebCast讲授一个系列的C++/CLI,也就是VC++ 2005的语言内核。下面是这个系列的介绍。其中(1)和(2)分别安排在4月20日和4月28日。欢迎对C++/CLI感兴趣的朋友来这里http://www.microsoft.com/china/msdn/default.aspx捧场:)

 

直接免费注册即可,对于时间不凑巧的朋友,MSDN中国在讲座之后提供有视频下载服务。

 

(1)VC++ 2005 (C++/CLI):基础概览
VC++ 2005(又称C++/CLI)是微软为广大C++程序员量身定做的,面向.NET平台的一门系统级编程语言。如何认识VC++ 2005?它为我们带来了什么?怎样才能学好VC++ 2005?本课程将对其做一概括性的介绍,并就这些热点问题做详细的探讨,帮助观众认识这一全新的编程语言。

(2)VC++ 2005 (C++/CLI):类型系统

类型系统是一门编程语言的“立身之本”,VC++ 2005由于对ISO-C++和CLI实现了集成而使得其类型系统在突显强大的同时,也凭添了许多复杂。本课程将对VC++ 2005包含的两大类型系统:托管类型系统和本地类型系统,及其可能的混合体进行全面的探讨,为您建立一个清晰的类型图景。

(3)VC++ 2005 (C++/CLI):类型成员

作为支持面向组件程序设计的编程平台,CLI和ISO-C++有着迥异的设计思路,其中一个表现就在类型成员的设计上。本课程将向大家介绍CLI托管类型系统中的各种成员(除析构函数),包括字段、方法、构造函数、操作符、属性、事件以及应用在它们之上的各种修饰,并就它们和ISO-C++本地类型系统中的类型成员做横向的比较。

(4)VC++ 2005 (C++/CLI):确定性资源清理

确定性资源清理是C++/CLI中提出的一个新的语言特性,它利用C++便捷的语法,简化了.NET应用程序开发时对非托管资源的处理,而这在其他.NET语言中需要繁杂的Dispose模式才能实现。本课程将对C++/CLI中确定性资源清理所涉及到的语法构造、运行机理等进行深入的剖析。

(5)VC++ 2005 (C++/CLI):指针与对象模型

指针是C++语言的精髓,也是C++语言的难点,由于CLI平台的托管特性,C++/CLI中出现了各种指针的变体,可谓难上加难。为什么C++/CLI的指针类型如此复杂?因为C++/CLI背后的对象模型非常复杂。C++/CLI中的指针类型完整映射了ISO-C++本地世界和CLI托管世界所包含的所有对象模型。本课程将从本地对象模型和托管对象模型入手,步步深入,探讨C++/CLI中的各种指针。

 

(6)VC++ 2005 (C++/CLI):元数据与动态编程

如果问CLI和ISO-C++最大的区别是什么?答案一定是元数据。元数据是CLI组件平台的灵魂,它在构建整个CLI组件平台中居功甚伟。在夯实CLI各种组件基础设施的同时,元数据也赋予了CLI强大的动态编程能力。本课程将从元数据入手,探讨C++/CLI中的动态编程。

(7)VC++ 2005 (C++/CLI):泛型编程

泛型编程在C++领域中早已深入人心,它赋予了类型参数式多态的能力,这种能力在ISO-C++中以编译时的模板实例化为依托。而CLI借自己强大的元数据系统,选择了运行时的模板实例化来支持泛型编程。C++/CLI在保留ISO-C++“编译时泛型编程”的同时,也增添了对CLI“运行时泛型编程”的支持。本课程将着重介绍C++/CLI中的“运行时泛型编程”,并将它们和“编译时泛型编程”做横向的对比。

 

(8)VC++ 2005 (C++/CLI):与ISO-C++的集成

在选择支持CLI的问题上,C++/CLI大胆地选择了“集成”而非“替换”的策略。同时支持ISO-C++和CLI两种编程方式并不复杂,但如何将二者在对象模型的层次上集成在一起则是一个非常复杂的问题。本课程将以ISO-C++本地对象模型和托管对象模型为纲,介绍C++/CLI中的集成技术。

(9)VC++ 2005 (C++/CLI):非托管互操作

代码重用是任何一个编程平台、语言都不可忽视的问题,C++/CLI同样也不例外。实际上C++/CLI不仅支持模块级(DLL动态链接库)、和组件级(COM组件)的重用,同时也支持源代码级(IJW,It Just Works技术)的重用。本课程将介绍这些互操作技术。

 

BTW,本周六在徐家汇有IT俱乐部的4月线下活动(http://www.chinaitclub.org),主题是Windows 移动开发平台,嘉宾为同济大学的何宗键先生,何先生是微软 Windows 嵌入式开发认证讲师,在嵌入式/移动开发领域有很好的造诣。对移动开发感兴趣的朋友,不可错过。

 

IT俱乐部活动·上海·美罗大厦·高级Windows调试

Categories: 未分类
Tags:
Comments: 7 Comments
Published on: 2005 年 03 月 16 日

IT俱乐部新春首期活动:高级Windows调试

3月20日(周日),上海·徐家汇·美罗大厦

主讲人为来自Intel的有9年WINDOWS平台工作经验的资深软件工程师张仁魁(Raymond Zhang)先生。张先生将以著名的蓝屏死机问题(BSOD)为线索,层层剖析Windows内核,畅谈高级Windows调试技术,对于喜欢底层体验的程序员来说,不可错过。

除了2个小时的技术主题外,我们还设置了1个小时的软件开发及软件人的成长主题交流论坛,供大家畅所欲言。

 

已经注册的用户不必再注册,我们会根据用户的情况进行筛选。对俱乐部感兴趣的新用户可以到这里http://www.zhucheng.biz/club/club.aspx了解情况并注册。

BTW, 年前1月23日的我的Effecitive.NET活动相关图片和ppt可参见这里http://www.zhucheng.biz/club/record.aspx

由于近来忙于融资和公司搬迁的事情,网站也在进行全面改版,所以在外部显得有些工作停滞,希望各位朋友理解。不过大家很快将会看到IT俱乐部的发展,同时也欢迎各界朋友为IT俱乐部献计献策,共商合作。比如筹建IT酒吧、IT书屋、IT KTV等……

 

 

Web讲座:VC++ 2005 确定性资源清理 (Deterministic Cleanup )

Categories: 未分类
Tags:
Comments: 7 Comments
Published on: 2005 年 02 月 23 日

明天我在微软MSDN上有一个C++/CLI方面的技术讲座Webcast:

讲座主题:VC++ 2005:确定性资源清理

活动日期:2005年2月24日 14:30–16:00

http://www.microsoft.com/china/msdn/events/webcasts/Webcast/webcast_Feb05.aspx

欢迎各位对C++/CLI(VC++ 2005)感兴趣的朋友捧场。

Web授课是个好东西,只要你有一台电脑就可以很方便地参加,消除了很多地域限制。今后祝成科技的咨询/培训组也会在网上推出一些精品的系列网络课程,其中正在制作的就有我的C# 2.0和VC++ 2005课程,希望能满足各地朋友的需要。

 

无独有偶,Herb Sutter在Channel9上也有两段video:

Herb Sutter – The future of Visual C++, Part I (http://channel9.msdn.com/showpost.aspx?postid=39280

Herb Sutter – The future of Visual C++, Part II(http://channel9.msdn.com/ShowPost.aspx?PostID=39463

非常值得一看。

 

 

«page 1 of 2
Welcome , today is 星期日, 2017 年 03 月 26 日