细说ＶＢ．ＮＥＴ（中）

细说ＶＢ．ＮＥＴ（中）（作家：青苹果处事室编写翻译　2001年03月07日 14:47）容易反编写翻译的中央谈话 　　不管你用vb、c#或其它.net谈话编写运用步调，vs.net代码都编写翻译变成中央谈话(il)。当运用步调运转时，一个立即编写翻译器(jitter)处置il代码并把它编写翻译变成呆板谈话。这表示着在表面上大概为windows除外的平台创造.net运转库，但此刻对于一致的工作还没有任何官方动静。中央谈话的一个缺点是：它像vb5往日的vb本子一律，简单被反编写翻译。这种大概性使很多开拓者一致地置疑.net框架结构的安定性。 　　clr在il档次表里感化代码，对它的窜改将使一切运用clr的谈话受益。但是，谈话不过和代码怎样被证明为il相关，对一定谈话的优化不妨按照一定谈话的语法来编写，如许在本领上就大概使.net谈话之间的本能分辨很小。尽管还好吗，大概上宏图是优美的。比方，clr使vb的调节和测试和监测东西和c#的相映东西十分，它做到了这一点由于它们从来即是沟通的东西。 　　clr供给不屈行的跨谈话集成，囊括跨谈话接受代码的本领。一切运用clr的谈话共享一个通用典型体例，它使运用多种谈话开拓运用步调变得更大略。我不爱好把 c api 证明翻译成vb里不妨运用的情势，以是我很赞美通用典型体例带来的长处。 　　在clr中运转的代码被称为被处置代码，被处置代码运用的外存实足由clr来遏制。被处置代码带来很多长处，囊括跨谈话集成、跨谈话特殊处置和简化的元件彼此效率模子。visual basic被控制为只能以被处置代码的办法处事，但是c#具有跳到非被处置代码的本领(实行到运转库除外)，并能做像南针操纵这类工作。这是vb和c#不一致的情景之一。这种本领究竟有多要害在于于你想干什么。 　　clr形成的体制构造分辨要比跨谈话集成、共享功效和被处置代码等深沉。开始，visual studio.net的维持构造不是 com。其余，vb.net里的一切货色，以至字符串都是东西。由于那些和其它少许因为，microsoft变换了维持构造处置东西的办法。com实行了一个援用计数计划，如许历次援用一个东西时，计数器递加。当一个东西援用胜过效率域或被开释时，计数器减产，当援用计数缩小到零时就中断这个东西。microsoft宣称在.net框架结构下援用计数的开支太大，及至于不许在 .net中实行它，以是它停止了援用计数转而运用废物搜集。 废物搜集须要新体制构造 　　clr废物搜集器主假如监督一个步调的资源，当可用资源到达决定的阈值时探求无效的东西，并在创造它们的功夫废除那些东西。废物搜集的第一次全国代表大会长处即是你不复须要担忧大普遍普遍的轮回援用，即子东西援用了父东西，而后父东西又援用了子东西。在援用计数计划下，轮回援用使两个东西都不许被开释和废除。但是，废物搜集器会创造轮回援用并废除它们。这也表示着开释东西的结果一个援用时不复须要登时废除东西。 　　废物搜集的一个成果是：你再也不许巴望一个类的 terminate 事变能在符合的机会发出。本质上，即使线程被阻碍，大概基础就不会发出 terminate 事变。和com供给的决定化中断差异，它被称为不决定的中断。不足决定化中断，以及由于废物搜集珍视新安置并收缩外存进而不许运用南针的究竟，在消息组里激励了一波剧烈的商量。我想那些新控制大概会令你悔恨，由于你要依附决定化中断；也大概你不闻不问，由于你不依附 terminate 事变。废物搜集并不是万仙丹，实行弱援用仍旧须要做少许商量。 　　从援用计数到废物搜集不过 visual studio.net 的维持构造不是 com 这个究竟的现象之一。你能在vb.net中运用com东西，比方说activex效劳器或activex控件。但是，你必需经过包装考察那些东西。任何功夫听到“包装”这个术语，你该当领会你面临着本能丢失，而且东西的动作大概有所各别。即使当安置移植一个运用了洪量com东西的工程，就须要刻意地尝试和安置，大概须要从新筹备运用步调的构造本领移植胜利。爽快地说，你要有蒙受妨碍的筹备。还牢记从vbx迁徙到 ocx的进程吗？我牢记，我的精力病大夫也牢记。我很快就要再去看他了 ;-) 　　谈话自己的变革要远远胜过体制构造的变革。大局部变换确有原因，但我并不觉得一切的变换都是如许。往日本子的vb承诺你以很多本领来做很多事，及至于一致的源代码规范要么不生存要么就很难强加于人。microsoft对vb做了洪量的变换为的即是“明显”这种谈话。很多情景下，从来你有好几种本领做一件事，此刻就惟有一种了。billy hollis 供给了语法变革的精细列表，囊括废除的要害字列表，但有些货色须要在这边反复一下。 　　开始，向进程参数传播数据的默许本领由援用(byref)形成了传值(byval)。这个变换主假如由于援用要比传值的危害大得多。它的危害主假如挪用进程中的数据大概被偶尔中窜改。你仍旧能经过援用传播数据，但这一变换使你须要窜改新的默许挪用本领来运用援用。 set语句消逝了 　　其次，set 语句消逝了。在 vb.net 里即使你须要向变量传播一个东西援用，所须要的不过一个等号，东西被视为同其它值一律。这很酷，但也有副效率：默许属性消逝了。比方，你不复能用这种办法援用一个属性： 　　text1 = "what, me worry?" 　　动作代替，你必需显式地援用属性： 　　text1.text = "what, me worry?" 　　大概一眼可见不须要这种变换，但真实必需去掉默许属性。比方，假设你有一个叫objfoo的东西变量，不必set语句，底下的语句所树立的援用就爆发了歧异性： 　　objfoo = text1 　　这条语句是该当树立到text1的援用，仍旧以text1的text属性来弥补objfoo？你不许决定，编写翻译器也不许。唾弃set语句同声诉求唾弃默许属性。 　　有一个变换我不爱好：你不复能在各别的效率域里证明property get和property set进程。提防 vb.net 没有 property let 语句：东西和数值都用 property set。这表示着你不许用一个 friend property let 进程来对应一个 public property get。用vb创造组件时大概会有烦恼。很多组件开拓者创造 friend property set 进程以使她们的运用步调能变换一个值，但供给 public property get 进程以使她们的存户步调能取回值。我蓄意我能为这个变换找到一个符合的来由，然而我找不到。 　　microsoft说它力求使谈话维持明显并使之新颖化—大局部情景下它做得不错—但这个效率域题目和其它几个题目令人感触迷惑。比方，while...wend 很早往日就该当消逝了，由于 do...loop 实行同样的功效。但是，microsoft 不只没能去掉 while...wend，还把它改成了 while...end while 来给本人找了更多的烦恼。真怪僻！ 　　我最不爱好的变换是：microsoft变换了你仍旧运用的数据典型含意。在 .net 里，integer 此刻是 32 位，而 long 形成了 64 位。我心存畏缩地想：开拓者 (囊括我本人) 会如许一再地运用缺点的变量啊。谁人api究竟是接收一个16位的 integer仍旧32位的？老天！我蓄意microsoft从新商量这个确定并运用新的变量典型，比方int32和long64。不管迁徙到 vb.net的移植东西是如许的好，它也不许变换开拓者的回顾。干什么要逼着咱们再学一遍普遍的数据典型呢？ 　　结果，最须要的一个变换是：vb.net引入了 option strict 要害字，你不妨运用它来包办 option explicit。option strict 中断了万恶的典型强迫(tm)，经过它vb乐于让你把一个数值赋值给一个字符串，而后像不法一律做另一个操纵。树立 option strict 报告 visual basic.net 不要为你做任何典型强迫。提防 vb.net 并不是完全的遏制狂，它承诺典型向下变换，但不承诺进取。比方，不运用像 sngvariable = csng(dblvariable) 如许的语句举行显式典型变换，你就不许把证明为 single 的变量赋值给证明为 double 的变量。由于这有丧失数据的危害。但是，你能不运用显式典型变换就把证明为 double 的变量赋值给证明为 single 的变量，由于这并没有丧失数据的伤害。运用 option strict 能扶助开拓者缩小很多典型缺点，囊括那些很难调错的。但有一个附加的缺点：在工程里运用了 option strict 后，就不许举行 后编联了。 <<<<<上一页：大纲、vb赢得了接受本领、十足都是东西、自在线程的伤害 >>>>>下一页：表单和新ide面貌、创造编写翻译的效劳器端代码