优于VB？ [英] Advantage over VB ?

问题描述

C＃比VB.NET有什么优势吗？或者差别只是语法

？可以在C＃中完成任何无法在VB.NET中完成的事情吗？

Is there any advantage in C# over VB.NET ? Or the difference is only syntax
? Can anything done in C# which cannot be done in VB.NET?

推荐答案

C＃中的调试更容易因为C＃在

未处理的异常上提供

Debugging is easier in C# beause C# provides an

异常变量。在VB.NET中你要抓住异常来检查异常细节。这会产生一个问题，因为捕获

异常也意味着范围从实际发生的异常

变为现在异常被捕获的位置，留下

局部变量和一般对象状态信息不可用。我根本没有看到这个问题，当我在VB.NET小组中提起这个问题时，它被解决了一个非问题。对我来说，这是足够的理由使用C＃。


另一个优点是C＃中不安全的代码块的可用性。如果

你不使用它们，那么它们不是一个优势。


VB.NET也存在严重的二进制序列化问题对象

具有事件，因为属性无法应用于

编译器生成的事件字段。唯一的解决方法是在单独的对象中声明

事件，这可能意味着使用纪念品

进行序列化。这在.NET 2.0中得到修复，但修复需要大量代码（20-30行），而只需要1行
C＃中的
（属性） 。


还有很多风格，语法和IDE的差异，但它们没有真正的问题，只是个人偏好的问题。


HTH，


Sam

周五，2005年3月4日01:32:35 +0500，Arsalan ;

< ar *********** @ hotmail.com>写道：

exception variable on
unhandled exceptions. In VB.NET you ahve to catch the exception to
inspect exception details. This poses a problem as catching the
exception also means the scope is changed from where the exception
actually occured to now be where the exception is caught, leaving
local variables and general object state information unavailable. I
haven''t seen this problem discussed at all and when I brought it up in
the VB.NET group it was brushed off as a non-issue. To me this is
enough of a reason to use C#.

Another advantage is the availability of unsafe code blocks in C#. If
you don''t use them, then they''re not an advantage though.

VB.NET also has serious problems with binary serialization of objects
that have events since attributes can not be applied to the
compiler-generated event fields. The only work-around is to have the
events declared in a separate object, possibly implying use of memento
for serialization. This is fixed in .NET 2.0 but the fix requires a
significant amount of code (20-30 lines) whereas only 1 line is needed
in C# (the attribute).

There are also lots of stylistic, syntax, and IDE differences but they
pose no real problems and are simply a matter of personal preference.

HTH,

Sam
On Fri, 4 Mar 2005 01:32:35 +0500, "Arsalan"
<ar***********@hotmail.com> wrote:

C＃比VB.NET有什么优势吗？或者差别只是语法
？可以在C＃中完成任何无法在VB.NET中完成的事情吗？

Is there any advantage in C# over VB.NET ? Or the difference is only syntax
? Can anything done in C# which cannot be done in VB.NET?

B-Line现在正在招聘一个华盛顿特区VB.NET

开发者为WinForms + WebServices职位。

中级到高级开发人员。获取

信息或将电子邮件简历应用于

sam_blinex_com。

B-Line is now hiring one Washington D.C. area VB.NET
developer for WinForms + WebServices position.
Seaking mid to senior level developer. For
information or to apply e-mail resume to
sam_blinex_com.

更多谈话要点：


VB.NET缺少C＃'s" using（）{}"代码块，我发现 - 哼 -

处理IDispoable对象必不可少。我非常想念它，因为我需要在VB.NET中编写代码。


C＃区分大小写，而VB不区分大小写。关于哪个更好，有无数的b / b
宗教辩论。我从一个

不区分大小写的语言（Visual FoxPro）来到C＃，并且最初发现案例

敏感度略有烦恼，但很快就适应了。两年后，在最近被推入一个VB.NET项目之后，我发现了一个案例

不敏感而不是烦恼（虽然仍然不是一个大问题） ）。

你的里程可能会有所不同。


VB.NET对C＃有两件我喜欢的东西。一个是

随着/结束 - 一些C＃人认为这是邪恶的化身，但我个人/ b $ b个人喜欢这种语法糖（是的，我们在VFP中也有它） ）。那个

说，在C＃中实现所有性能优势并不是什么大事。

With / End With，如果不是100％的紧凑性，简单来说，简单来说为一个简短的变量名称分配一个

冗长的分层引用并使用它来转发

。

VB的另一件事。 NET认为C＃缺少的是可选参数。

再次，你可以在C＃中实现几乎相同的重载，但是

可选参数确实使得一些Interop工作 - 特别是ActiveX

自动化 - 更少繁琐且容易出错的代码。


因为我还没有需要它，对我而言陪审团仍在外面

VB.NET和Option Strict Off（支持后期绑定，代表你做了很多代表System.Reflection的b
）。从理论上讲，这应该会使一些后期绑定工作变得更容易，但我实际上还没有做到这一点

并且想知道它是否是这些功能之一我自己最终会做到这一点

我希望它做得对。


这带给我们VB.NET的精神，这是尝试做尽可能多的细节

默认情况下为你工作，与C＃相比，这往往会减少对你想要完成的事情的假设。根据具体情况，这两种方法都可以阻碍完成工作。再一次，在我看来，我真的很喜欢，但我还是赞成C＃的不干涉方法;我想b $ b不想被二次猜测。


关于VB.NET的冗长/笨拙总是存在宗教争论

vs C＃的简洁/优雅。我个人有一个明显的偏好

用于C风格的语法，至少是Java或C＃说服，而不是

下划线和宏出现的垃圾很多C ++代码似乎是。

但是，虽然VB.NET中的编码让我不时做鬼脸，但是这不是那么大的交易。它就是它。


VB.NET有一些传统的包袱来支持VB6和之前，C＃能够避免
。例如，如果你是一个旧的VB6 warhorse，你可能会使用

CInt（obj）或CType（obj，Integer）而不是Convert.ToInt32（），如果你是

是一个多语言的.NET开发人员，你可能会喜欢逆向。

如果你没有VB

背景，这确实会创造一些额外的学习曲线，实际上这又是一个小问题。经过几次发布后，C＃将拥有自己的传统行李，所以它在优雅/清洁竞争中的领先优势是相当临时的。


两个最终决定支持C＃的因素：


1）虽然MSFT明确致力于VB.NET，但C＃就像很明显，MSFT'

青睐的孩子。它是专门为.NET创建的，尽管最近好的东西已经变得更好了，但是最好的例子有一个早期趋势，即最新的例子和最新的玩具是C＃ - 只是。实际上，新的功能已经承诺首先用于
C＃，而在未定义的未来日期则用于VB.NET;很长一段时间它没有承诺或确定泛型会进入VB.NET

版本2.0。最终它确实如此，但事实上，VB社区已经开始鼓励它了。所以我喜欢C＃，因为它的制造商似乎有一个

中等偏好的地位（尽管有些第三方供应商支持VB.NET;例如IronSpeed Designer只生成VB .NET代码

直到最近。）


2）政治。在VB.NET是一个玩具的世界中，有一个99％的虚假但持久的感觉出现在国外。语言和/或它不是严肃的

项目（无论究竟是那些）和/或倾向于吸引更少的b $ b b熟练的开发人员。相反，在世界范围内，C＃是一个成年人，在世界范围内存在99％的虚假但持久的感觉。语言和/或它

更优雅/更快/更好/增长你的头发和/或吸引

更好的开发人员。我称之为Curly Brace Effect（我的上帝，Edna，如果他能读出那些他必须*是天才的东西！）。作为一名C程序员（无论是Java，C＃，还是特别是C ++），没有人会把沙子踢成你的脸。

另一方面，你可以相当容易被解雇为VB

程序员。不公平，但也是如此。因此，对于那些认为语言是一切关键的纯粹适销对象而言，我认为语言是一切的关键，我将自己定位为

a C＃开发者。


当然，实际上没有人是C＃或VB.NET或Eiffel.NET开发人员;我们

都是最喜欢语言的.NET框架开发人员。


--BOB


" Samuel R. Neff < BL **** @ newsgroup.nospam>在消息中写道

news：9q ******************************** @ 4ax.com ...

More talking points:

VB.NET lacks C#''s "using () {}" code block, which I find -- ahem --
indispensable for dealing with IDispoable objects. I really miss it when I
have to code in VB.NET.

C# is case sensitive, whereas VB is case-insensitive. There are endless
religious debates about which is better. I came to C# from a
case-insensitive language (Visual FoxPro) and at first found case
sensitivity a slight annoyance, but quickly adapted. After being thrust
recently into a VB.NET project two years later, I am finding case
insensitivity to be *more* of an annoyance (though still not a huge deal).
Your mileage may vary.

There are two things that VB.NET has over C# that I rather like. One is
With / End With -- some C# people think this is evil incarnate, but I
personally like this syntax sugar (and yes, we had it in VFP too). That
said, in C# it''s no big deal to achieve all the performance advantages of
With / End With, if not 100% of the compactness, by simply assigning a
lengthy hierarchical reference to a short variable name and using that going
forward.

The other thing that VB.NET has that C# lacks is optional parameters.
Again, you can acheive almost the same things in C# with overloading, but
optional parameters really makes some Interop work -- especially ActiveX
Automation -- much less tedious and error-prone to code.

Since I haven''t had the need for it yet, for me the jury is still out on
VB.NET and Option Strict Off (support for late binding that does a lot of
tedious calls into System.Reflection on your behalf). In theory this should
make some late binding work easier, but I haven''t actually had to do it yet
and wonder if it''s one of those features where I''d end up doing it myself it
I wanted it done right.

Which brings us to the ethos of VB.NET, which is to try to do as much detail
work for you as possible by default, vs C#, which tends to make fewer
assumptions about what you are trying to accomplish. Both approaches can
get in the way of getting things done, depending on the context. Again, in
my view, really a wash, but I moderately favor C#''s hands-off approach; I
don''t like to be second-guessed.

There is always the religious debate about verbosity / clunkiness of VB.NET
vs the terseness / elegance of C#. I personally have a distinct preference
for C-style syntax, at least of the Java or C# persuasion as opposed to the
underscore and macro infested crap that a lot of C++ code appears to be.
But, although coding in VB.NET makes me grimace a little from time to time,
it''s not that big of a deal. It is what it is.

VB.NET has some legacy baggage to support VB6 and prior, that C# was able to
avoid. For example if you are an old VB6 warhorse you would probably use
CInt(obj) or CType(obj,Integer) rather than Convert.ToInt32(), and if you
are a multi-language .NET developer you would probably favor the inverse.
Though this does create some extra learning curve if you don''t have a VB
background, it is in fact once again a minor deal. And after a couple more
releases, C# will have legacy baggage of its own anyway, so its lead in this
division of the elegant / clean competition is fairly temporary.

Two final deciding factors in favor of C# for me:

1) While MSFT is clearly committed to VB.NET, C# is just as clearly MSFT''s
favored child. It was created specifically for .NET, and although things
have gotten better lately, there was an early tendency for the best examples
and newest toys to be C#-only. Indeed, new features have been promised for
C# first, and for VB.NET at some undefined future date; for a long time it
was not promised or certain that generics would make their way into VB.NET
with version 2.0. Ultimately it did, but the fact that the VB community had
to agitate for it is telling. So I like C# because it seems to have a
moderately favored status with its maker (although some third party vendors
favor VB.NET; for example IronSpeed Designer only generated VB.NET code
until recently).

2) Politics. There is a 99% bogus, yet persistent, perception abroad in the
world that VB.NET is a "toy" language and/or that it is not for "serious"
projects (whatever precisely those might be) and/or tends to attract less
skilled developers. Conversely there is a 99% bogus, yet persistent,
perception abroad in the world that C# is an "adult" language and/or that it
is more elegant / faster / better / grows hair on your chest and/or attracts
the better developers. I call it the Curly Brace Effect ("my God, Edna, if
he can read that stuff he *must* be a genius!"). No one ever kicks sand
into your face for being a C programmer (be it Java, C#, or especially C++).
On the other hand you can be fairly readily dismissed for being a VB
programmer. Unfair, but true. So for pure marketability to pointy-haired
bosses who think the language is the key to everything, I position myself as
a C# developer.

Of course in reality no one is a C# or VB.NET or Eiffel.NET developer; we
are all .NET framework developers with a favorite language.

--Bob

"Samuel R. Neff" <bl****@newsgroup.nospam> wrote in message
news:9q********************************@4ax.com...

C＃中的调试更容易，因为C＃提供了

Debugging is easier in C# beause C# provides an

这篇关于优于VB？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！