c#相对于Windows应用程序的delphi/realbasic有什么优势[关闭]答案

【问题标题】：What are the advantages of c# over, say, delphi/realbasic for windows applications [closed]c#相对于Windows应用程序的delphi/realbasic有什么优势[关闭]
【发布时间】：2009-02-13 22:53:33
【问题描述】：

有没有人写过比 .NET 包还大的应用程序？人们过去常常批评 VB6 的 2 MB 运行时，但它很少使它附带的应用程序相形见绌。

今天，尽管我的机器上安装了 Vista，但我必须下载 35 MB 的 3.5 框架并重新启动，然后才能试用一半大小的应用程序。

当您考虑到源代码安全性降低时，我想知道为什么有人会在 .NET 中开发 Windows 应用程序，而不是使用允许构建本机可执行文件的语言。

在编写在 Windows 上运行的应用程序时，.NET 有什么优势可以克服这些缺点？

【问题讨论】：

值得指出的是，对于我的使用（在工作中），您的任何否定对我的使用都没有任何意义。我认识一些真正喜欢 delphi 的 LOB 程序员，但是当 .net 第一次问世时，棱镜在哪里...... 以后变得更好并不会削减它
@ShuggyCoUk：好的。你终于失去了它。显然，当 .NET 第一次出现时，Delphi 不可能存在，因为 Delphi 不是由 MS 制造的。您的论点与“普锐斯永远不会出售，因为 T 型车刚问世时它还不存在”是一样的。新闻快讯：最近可能会更好。
我没想到它一出现就立即出现了，但是.Net 在 2000/2001 年问世了！即使等到 2.0 功能到位（合理的事情）也意味着 2004 年！
如果您专门讨论 Win32 中的 Windows 应用程序，很难提出使用 C# 而不是 Delphi 的好论据，因为 特定环境 Delphi 是有史以来最好的东西
@ShuggyCoUk - 以后变得更好正是微软这些年来一直在做的事情。到目前为止似乎没有伤害到他们。

标签： c# .net delphi realbasic xojo

【解决方案1】：

人们：请注意，这是在 2009 年 2 月 写的，并且说的是当时 - 在 2012 年末（3 年以上）对我大喊大叫后来）是没有意义的。 :-)

Delphi 对于 Win32 有一些相当大的优势。并不是说 .NET 应用程序天生就不好，而是尝试：

在不存在 .NET 的 Win95/ME 上运行 .NET 应用程序（任何版本）（AFAIK）
分发任何小型 (
在无法访问 Internet 的系统上提供任何 .NET 应用程序（是的，它们存在）
在没有广泛高带宽的国家/地区分发您的 .NET 应用程序
不花很多钱就让人们看不到您的源代码（反思，有人吗？）

.NET 中的垃圾收集可能非常好，但是任何了解编程的人也可以使用 Delphi 轻松处理手动分配/释放内存，并且 GC 可用于引用计数接口。让所有非程序员大量使用 VB 的伪 GC 的原因不就是其中之一吗？ IMO，GC 是使 .NET 变得危险的原因之一，就像 VB 很危险一样——它使事情变得过于简单，并允许那些真正不知道自己在做什么的人编写最终会弄得一团糟的软件。（而且，在我在这里被火烧死之前，这对那些确实知道他们在做什么的人来说非常棒，VB 也是如此；我只是不太确定这样做的优势熟练的人比不熟练的人对我们的危害更大。）

Delphi Prism（AKA Rem Objects Oxygene，以前的 Chrome）提供了 Delphi 的 GC 版本，需要它的人正在寻找它，以及 ASP.NET 和 WPF/Silverlight/CE，具有可读性（并且缺少花括号) 的德尔福。对于那些（像我一样）Unicode 支持不是主要因素的人，Delphi 2007 提供了 ASP.NET 和 VCL.NET，以及本机 Win32 支持。而且，在像我工作的地方，当工作站（至少）每三年升级一次，我们刚刚淘汰了最后一台 Win95 机器，因为它不是升级的优先事项，.NET 框架是一个问题。（特别是公司代理要求只允许少数人访问 Internet，限制带宽和下载能力，以及不允许使用 USB 设备的适当非管理员帐户，所有这些仍然在 Netware 网络上运行 - 没有 Windows Update 之类的东西，以及到目前为止从来没有病毒，因为没有任何东西进入。）

我使用 .NET 语言（C#、Delphi Prism）工作，但全职和兼职都是来自 Win32 和 Delphi。

【讨论】：

如果你认为我应该拒绝有用的编程工具（并且通过推断你）因为白痴会滥用它们，那么我不能说我同意你的观点。不要雇用白痴，如果这对你在其他地方工作来说是个问题。
你们都误解了我的意思。 GC 本身并不危险；这是 GC 为白痴提供的便利，使他们能够生产令人担忧的软件。就像我说的，想想所有编写的 VB 应用程序——垃圾比黄金多得多。 :-)
我不明白 GC 如何让编写糟糕的代码变得更容易。如果有人在 .NET 中编写了糟糕的代码，那么将他们扔到非托管环境中肯定会是一场灾难。
@Ken White：哎呀，从 GC 的角度声称道德制高点有点不知情。平均而言，坏程序的百分比与 GC 无关 - 优秀程序的百分比。有更多的时间花在特性上，而不是手动 GC。 ;)
我将在一周中的每一天都使用 Delphi 而不是 C#。我不明白GC的爱。这并不难。如果您创建一个对象，请在完成后释放它。真的就是这么简单。

【解决方案2】：

好的，我怀疑这会说服您，因为您不想被说服，但这是我对 .NET 相对于旧技术的优势的看法。我不会声称所有优势都适用于您在问题中提到的每种语言，或者 .NET 是完美的，但是：

托管环境更早发现常见错误并提供新机会：
- 强类型可避免将一种类型错误地视为另一种类型
- 垃圾收集很大程度上消除了内存管理问题（我承认并不完全）
- “Segmentation fault”通常转换为“NullReferenceException” - 但以更容易调试的方式！
- 没有缓冲区溢出的可能性（当然，除了潜在的 CLR 错误之外）- 这立即消除了一个重大的安全问题
- 声明式安全模型和精心设计的运行时允许代码在各种信任级别下运行
- JITting 允许 CLR 在 64 位机器上运行而无需重新编译（某些互操作情况除外）
- JITter 还可以针对未来的处理器开发，在开发人员无需任何工作的情况下进行改进（包括无需重新构建或分发多个版本）。
- 反射允许在非托管环境中完成各种不可能或困难的事情
现代的面向对象框架：
- 具有执行时间知识的泛型（与 Java 中的类型擦除相反）
- 合理的线程支持，在 .NET 4.0 中引入了一组新的原语（并行扩展）
- 从一开始就支持国际化和 Unicode - 一方面，只需考虑一种字符串类型 :)
- Windows Presentation Framework 提供现代 GUI 框架，允许声明式设计、良好的布局和动画支持等
- 很好地支持与本机库的互操作（例如，P/Invoke 所以比 JNI 好得多）
- 异常比错误代码提供更多信息（并且更容易处理）
- LINQ（在 .NET 3.5 中）提供了一种处理进程中数据的好方法，并提供了处理数据库、Web 服务、LDAP 等的各种选项。
- 委托允许从 VB 和 C# 进行某种功能性的编码风格；由于 lambda 表达式，这在 C# 3.0 和 VB9 中更好。
- LINQ to XML 是我用过的最好的 XML 库
- 将 Silverlight 用作 RIA 框架允许您在轻量级客户端和其他访问方法之间共享大量代码
- 一个非常好的版本控制故事，包括绑定重定向、运行时首选项等
一个框架针对多种语言：
- 共享组件比使用（比如）COM 更简单
- 语言选择可以由任务和团队经验驱动。从 .NET 4.0 开始，这一点尤其重要：在更适合函数式语言的地方，使用 F#；如果使用动态语言更合适，请使用 IronRuby 或 IronPython；在所有语言之间轻松互操作
- 坦率地说，我只是认为 C# 是一种比 VB 或 C++ 更简洁的语言。（我不了解 Delphi，但我听说过关于它的好消息 - 嘿，你现在可以使用 Delphi 来定位 .NET。）

其中大部分的结果（我猜也是其中的一部分）是 .NET 允许更快地开发更强大的应用程序。

解决您在问题中提到的两个具体问题：

如果您的客户正在运行 Vista，他们已经拥有 .NET 3.0。如果他们运行的是 XP SP2 或 SP3，他们可能至少有 .NET 2.0。是的，如果你想使用它，你必须下载更新版本的框架，但我认为这是一个很小的问题。我认为将应用程序的大小与框架的大小进行比较没有任何意义。您是否将应用程序的大小与操作系统的大小或 IDE 的大小进行比较？
我不认为反编译几乎像大多数人那样是一个问题。你真的需要想想你害怕什么：
- 如果您害怕别人复制您的实际代码，那么如果您了解基本设计，从头开始编写代码通常会容易得多。请记住，反编译器不会给出局部变量名称（假设您不分发 PDB）或 cmets。如果您的原始源代码仅与反编译版本一样易于理解，那么您的问题比盗版更大。
- 如果您害怕别人绕过您的许可并盗版您的代码，您应该记住在阻止人们盗版本机应用程序方面付出了多少努力，而且效果如何。
- .NET 的很多用途是在服务器上或用于内部应用程序 - 在这两种情况下，反编译都不是问题。
- 我在article about decompilation and obfuscation 中写了更多关于这个主题的文章。

【讨论】：

++ 写得也比我的好，猜猜如果我再得到两票，我就能得到一个纪律严明的徽章。
@Shuggy：见鬼！请不要删除你的 - 它比我的回答更能说明“优点和缺点”。我敢肯定那里也有很多不重复的地方。
@Jon：不错的帖子。我会辩论几点，但在 cmets 中没有任何有价值的空间。 :-) 仅供参考，不过，Delphi 有一个相当不错的 OOP 框架（我承认没有那么广泛），并且从 D2009 开始支持泛型和匿名方法。它也完全支持 Unicode。
是的，我猜 Delphi 将是最难争论的，尤其是它可以针对 .NET。不幸的是，除了它是 Anders 的另一部作品之外，我对 Delphi 几乎一无所知，并且它具有某种“静态多态性”。（我知道这个概念大致是什么，但不知道它的名字。）
我非常喜欢 Delphi Prism 中支持的期货/异步概念。该产品仅在商业基础上提供，这意味着我不太可能尝试它。

【解决方案3】：

仅举几例：

自动内存管理、垃圾回收
类型安全
边界检查
无需创建即可访问数千个课程

【讨论】：

+1“你不必创建的数千个类”
-1 类型安全。几十年来，德尔福 (TP 1) -1 进行了边界检查。 TP 2 离开。 GC - 有问题。上课？ Delphi 也有很多，虽然我不确定它们是否与“数千”一样多（您实际上在 Delphi 和 .NET 中计算过它们吗？）
续：指向已释放内存的单个悬空指针会破坏您的类型安全性：如果在同一位置分配了不同类型的值，则会出现类型冲突
达林，你几乎是对的。 “悬空指针”当然不是类型安全的；然而，如果你是一个让指针悬空的白痴，你就不应该编程。并且要使用 Win32 API（这将需要很长时间），您需要指针，即使在 C# 中也是如此。
@Mason Wheeler：查看关于对象所有权、接口和引用计数或如何正确使用 try finally 的 Delphi 问题的数量，您将看到手动内存管理对于许多程序员的问题至少和你认为的 GC 一样多。

【解决方案4】：

好的，首先，没有一种语言/平台会普遍优越。

专业化将始终在某些领域提供更好的用例，但通用语言将适用于更多领域。
多范式语言将受到范式之间复杂边界情况的影响，例如
- 以任何函数式语言进行类型推断，在呈现子类时也允许 OOP
- C++ 的语法异常复杂，这直接影响到其工具链的能力。
- C# 中 co/contra 方差与泛型相结合的复杂性很难理解。

较旧的语言将拥有可以工作的现有代码库，这既是积极的（经验、经过充分测试、广泛的支持文献），也是消极的（由此产生的对变化的惯性、多种不同的做事方式导致新进入者的困惑)。

语言和平台的选择/使用与大多数事情一样，是利弊的平衡。

在以下列表中，Delphi 有一些相同的优点和缺点，但也有很多不同。

潜在 .Net 的负面影响（如果它们对您来说不是问题，那么它们就不是负面影响）

是的，您需要部署（和安装）运行时，而且它很大。
如果您想要一种具有多重继承的语言，您将不会得到它
BCL 集合库存在一些严重缺陷
在 MS 领域之外没有得到广泛支持（单声道很棒，但它明显落后于官方实施）
潜在的专利/版权产权负担
Jitted（忽略 ngen）启动时间总是会变慢，并且需要更多内存。

还有更多，但这些是亮点。

潜在积极因素（如果它们对您不重要）

通用 GC，没有阻止某些数据结构可用的引用计数，我知道没有没有 GC 的广泛使用的函数式语言，我想不出至少没有可选 GC 的过去 10 年的重要语言。如果您认为这没什么大不了的，那么您似乎是少数人。
大型 BCL（有些部分不如其他部分好，但非常宽泛）
可以使用大量语言（以及数量惊人的范例）并相互交互（我在一个更广泛的应用程序中使用 c#、f#、C++/CLI彼此之间）。
功能齐全的内省与声明式编程支持相结合。通过这种方式，各种框架变得更加简单易用。
Jitted - 底层 CPU 架构的更改可以在很大程度上是透明的，预编译语言不具备的复杂运行时优化是可能的（java 目前在这方面做得更好）
内存访问安全
Fusion dll 加载和系统 dll 的 GAC

同样适用于 c#

缺点：

基于 C 基础的语法
（4.0 之前）仅通过继承进行后期绑定
比某些命令式语言更冗长
对复杂的嵌入文字（正则表达式/xml/多行字符串）处理不当
闭包中的变量捕获可能会令人困惑
嵌套生成器既笨重又性能糟糕

专业版：

基于 C 基础的语法
通过 lambda 提供大量功能支持
允许对非代码区域（例如 Linq to SQL）进行编译时验证的表达式
强类型化，但通过一些类型推断使这更容易
如果您真的需要不安全，可以为您服务
通过 P/Invoke 与现有 C++ ABI 代码的交互既简单又清晰。
内置多播事件模型。
轻量级运行时代码生成

C 基础确实是有利有弊。大量程序员都可以理解它（与基于 Pascal 的风格相比），但有一定程度的麻烦（switch 语句就是一个明显的例子）。

Strong/Weak/Static/Dynamic 类型系统是一个两极分化的争论，但毫无疑问，如果类型系统受到更多限制，它应该努力不要求过多的冗长，因此，c# 肯定比在这方面很多。

对于许多内部业务线应用程序而言，大量 .Net 平台的缺点是绝对无关紧要的（受控部署是公司内常见且已得到很好解决的问题）。因此，使用 .Net（这在很大程度上意味着 c#，对不起 VB.Net 的家伙）是 Windows 架构中新开发的一个非常明显的选择。

【讨论】：

【解决方案5】：

使用它开发复杂（和简单）应用程序的“简单性”。框架中已经为您编写了许多基本内容，您可以直接使用它。而且今天下载 35mb 的文件比 8-6 年前的 2mb 文件要容易得多。

【讨论】：

在delphi中开发非常简单，也可能是realbasic。有人说太简单了（见vb6）！
用 Visual Basic 开发简单的东西很简单。
与任何 .NET 语言相比，Delphi 更易于开发。
用vb6开发简单的东西很简单。但是尝试使用 Web 服务，在进程之间进行远程通信，在其中编写 Web 应用程序或 Web 服务，然后将其与 .Net 进行比较
看到 vb6 11 年没有更新了，这很令人惊讶吗？不过在delphi中可能是一个不同的故事

【解决方案6】：

有很多原因。我对 RealBasic 了解不多，但就 Delphi 而言：

不如 .NET 普及，开发社区更小。网上的很多 Delphi 资源都是古老而过时的。
在 Delphi 2009 之前，Delphi 没有完整的 unicode 支持。
我不知道 Delphi 2009，但 2007 没有很好的垃圾收集。它有某种笨拙的引用计数，需要代表开发人员进行一些干预。 .NET 具有更高级的 GC，几乎可以为您完成所有工作。
.NET 拥有更大的标准库和更多最新的第 3 方库。
.NET 语言（如 C#）可以说更好，而且对于语言新手来说当然更容易理解。

【讨论】：

Delphi 不那么普遍，但足够可行。有 Unicode 支持。对 GC 的优点进行了辩论，也许还可以在可选的基础上提供。第4点我不能说。 IMO Object pascal 读起来像 c# 象形文字的英文。拥有本机可执行文件并热衷于保持向后兼容性。
不能把 delphi.net 的所有东西都移植回 win 32 吗？原来这不是整个想法吗？
@Henk：引用计数不仅仅是字符串，而是；接口也是。 “向后兼容性”适用于 Delphi 2009 和 Unicode 之前的所有 Win 版本（D2009/.NET 之前）。我感觉到个人对 Delphi 的厌恶（而不是客观/专业）。想解释一下，还是只想显示偏见？
kjack，当我说更容易理解时，我是指已经有编程经验的人。很多人从 Java 或类 C 语言迁移到 C#，其中 C# 将比 Delphi 更熟悉。很多学习 Delphi 的教程都已经过时了，这也无济于事。
Delphi 在向后兼容方面堪称卓越的典范。事实上，CodeGear 最近展示了他们的演示应用程序如何与 Delphi 1 一起发布，仍然可以在 Delphi 2009 中按原样编译。Delphi v1 早在 14 年前就问世了！社区比 .NET 小，但非常活跃。

【解决方案7】：

这里有很多 .NET 开发人员引用的假定优势，但它们不应该在比较中，因为 Delphi 也有它们：

类型安全
边界检查
无需创建即可访问数千个类（组件）

然而，.NET 中有一些东西是 Delphi 没有开箱即用的，只有其中一些可以通过库和自己的代码添加。仅举几例：

支持在同一运行时运行的多种语言 - 允许为问题选择匹配的语言（例如，使用 F# 的函数式编程）
动态源代码生成和编译 - 这对 Delphi 程序员来说是如此陌生，以至于他们可能甚至不知道它有什么用处 [1]
多播事件
更好的多线程支持（例如 BackgroundWorker 类、异步委托）
无缝支持 32 位和 64 位进程
弱引用

[1] 如果您不知道但有兴趣，请查看home page of Marc Clifton，尤其是有关声明式编程的文章。

编辑：我想回复 Mason Wheeler 的评论：

关于动态代码：我知道有一些解决方案可以在应用程序中嵌入 Pascal 脚本。然而，将内部对象层次结构的一部分提供给脚本引擎，与在运行时用于代码的相同编译器之间存在明显差异。 Delphi 编译器和脚本引擎的编译器之间总是存在差异的。无论如何，您从 .NET 获得的东西远远超出了 Delphi 可用的任何东西。无论如何，是否能够为 Delphi 编写类似的基础架构并不是重点，重点是 .NET 已经为您准备好了，当您需要时。
重新多播事件：确实，有一些方法可以对其进行编码，但它不是 Delphi / VCL 开箱即用的一部分。这就是我上面所说的。
Re 弱引用：可悲的是，您误会了。尝试以不平凡的方式使用接口，在此过程中创建循环引用。然后你必须开始使用类型转换并希望弱引用。

【讨论】：

动态代码：我知道至少有 2 个功能强大、成熟的 Object Pascal 脚本引擎就在我的脑海中。多播事件：blogs.codegear.com/abauer/2008/08/15/38865 弱引用：谁在乎？这些只有在你使用 GC 时才重要。
@Mason：你是对的。有两个以上，虽然我不再卖我的了。在 Delphi 2 的日子里，我们有一个早期的（TCFEvaluator，在 Delphi 的 Clipper Functions 库中）。如果你愿意，你甚至可以引用它所在的表单的属性。）而且是在 .NET 之前。 :-)
@Ken：你真的看不出这与在运行时使用相同的开发工具有何不同吗？使用超出一些已发布属性的反射功能？
回复：您的编辑，特别是第 3 部分：首先，接口引用计数是 GC 的一种形式。其次，为 COM 创建接口——让您的 EXE 与外部代码对话。它们对其他任何事情都没有意义，除非您专门将它们用于引用计数。（续）
有各种依赖于此的 GC 技巧。它们都不需要我知道的循环接口引用。如果你有循环的外部引用，那么无论是你还是创建与你交互的代码的人都在做非常非常错误的事情。

【解决方案8】：

嗯，.NET Framework 是为所有 .NET 应用程序共享的，所以您的机器上只有一次，现在 35MB 不算什么（与您的 Vista 安装的大小相比）。对于您的第二个 .NET 应用程序，您不必再次下载它。

【讨论】：

好吧，我没有下载vista，框架很快就会再次改变。
有些人下载Vista ;-)
其实我昨天才更新windows（老实说），怎么今天还要下载.net呢？
您也可以通过 Delphi 的运行时包支持来做到这一点。由于运行时包，我有一些小于 250KB 的应用程序，它们是非常复杂且功能强大的应用程序。

【解决方案9】：

对于 Windows 应用程序，.NET（使用 C# 或其他）使您可以更直接地访问最新和最强大的 Windows 功能。它也得到了 Microsoft 的大力支持，拥有庞大的社区和很多关于它的书籍。

REALbasic（现为Xojo）适用于跨平台应用程序。仅在 Windows 上使用它有时会很有用，但这不是它的优势（因为它非常易于使用）。

我对 Delphi 了解不多。

【讨论】：

“它的力量” nazi> :)
这是“力量”nazi> :-)
语法和拼写纳粹需要学习专有名词如“纳粹”的大写。 :-) 说真的，人们：过上自己的生活。
"", ""
即便如此，使用没有开始标签的结束标签也是有问题的。真的，它不应该是一个空标签吗？

【解决方案10】：

据我所知，RealBASIC 在对象关系工具方面没有太多（如果有的话），并且可能不是 n 层、以数据库为中心的应用程序的好选择。

【讨论】：