H
huaiqiuqiu9
Unregistered / Unconfirmed
GUEST, unregistred user!
Java;Delphi;C#;C++哪个最有前途？（从收入的高低，从花费时间的多少）
回答这个问题一定要考虑“性价比”哦！
以下文章请大家看看：：：：：：
自C#诞生之日起，关于C#与Java之间的论战便此起彼伏，至今不辍。抛却Microsoft与Sun
之间的恩怨与口角，客观地从技术上讲，C#与Java都是对传统面向对象程序设计在组件化软
件时代的革新之果，可谓殊途同归。虽说两个语言有着"90%的重叠"，但那另外"10%的较量
"也往往能够左右一个天平的方向。本文将携90%之共，论10%之异，对两个语言做纯技术品
评。文章不涉及两个语言的公司，市场等台面后的事情--虽然这往往也会影响人们对编程语
言的选择。也不预备得出谁是谁的Killer，读者应该选择谁的问题。"语言选择乃艺术而非
技术问题"，业界早有定论，无需多言。
C#和Java都提出了对传统C++艰深，晦涩的语法语义的现代改良。在语法方面，两者都
摈弃了C++中函数及其参数的const修饰，宏代换，全局变量和全局函数等许多华而不实的地
方。在继承方面，两者都采用了更易于理解和建构的单根继承和多接口实现的方案。在源代
码组织方面，都提出了声明与实现于一体的更好的逻辑封装。在类型系统方面，两个语言都
在中间语言IL或字节代码的基础上提出了映射(Reflection)这样的概念，彻底革新了传统
C++运行时类型鉴别的问题。但在大刀阔斧地对C++进行改革的同时，C#显得更为保守，它
对很多原来C++中很好的性质予以了保留，如基于栈分配的轻量级的结构类型，枚举类型，
引用（ref），输出（out），数组（params）修饰的参数传递方式等，这些在Java中都被
很可惜地丢掉了。在基本类型和单根继承的对象之间的类型统一方面C#提出的box/unbox要
比Java的包装类显得高明，效率也要好。
对C++不安全的指针及内存分配方式，C#和Java都提出了托管执行环境。效率问题是托
管执行环境一直以来令人诟病的地方，Java虚拟机（JVM）的解释执行方式曾经让很多开发
者"慢的不可忍受"。C#的JIT编译方式为C#在这块战场上赢得赞声一片，某些C#托管代码甚
至比传统C++代码都快。虽然现在各厂商实现的Java平台也都一致地采取了JIT编译方式，
但C#在这方面的比较优势非常明显--C#的目标编译语言IL从设计初始就把效率摆在了重要
的地位，而Java的字节代码的设计却有些鲁莽。托管执行环境经过几年的实践，在现代软
件界已经达成了共识，效率的牺牲换来的是高度安全的代码--当然前提是牺牲的效率必须
足够的小，至少可以忍受。值得指出的是在这里C#同样"念念不忘老一辈C++程序员"，C#允
许我们在unsafe上下文中进行指针操作。数组的索引越界检查，类型安全在C#和Java中都
被提到了相当的高度。在异常处理方面，不管从内置支持，还是从执行效率来讲，C#都较J
ava略胜一筹。
"一次编程，多处执行"是程序设计一直以来的一个诉求，尤其是在现代互联网络时代。
在跨平台方面，Java的支持和实现都是为人称道的，虽然JVM的速度仍然让人备感头疼。
而C#虽然在底层构造方面对移植性进行了充分的考虑，但至少目前还没有成熟的，经过检验
的产品。C#在跨平台方面似乎更热衷于XML Web Services互操作，而不是跨平台编程。但
C#通过其基础语言构造（CLI）对二十多种主流语言的对象级的互操作支持，又极大地提升
了C#的技术地位。和COM组件廉价地互操作也为C#挣到不少分数--保持一个兼容的体系对现
代软件工业非常重要，也是对广大开发人员负责任的表现。
面向组件无疑是当代软件开发的主流。C#对组件编程甚至到了"迷恋"的地步，这与6年
前就出道的Java不可同日而语--当然这是时代问题。C#通过属性，索引器，委派，事件，
操作符重载，特征，版本等实现了其对组件编程的第一手的支持。虽然这些在Java中都可
以通过方法，接口或者适配器来间接地实现，但软件业的历史告诉我们这无论对编程效率
或者逻辑设计都是一种极大的损伤--高级语言首先面对的是人，而不是机器。除去这些语
言层面的组件支持机制，.NET平台也为组件的配置，运行，管理等提供了一揽子解决方案
，而为组件开发量身定做的Visual Studio.NET更是令人兴奋，这都为C#的组件编程开辟了
广阔的天地。在其他技术方面Java的微弱劣势尚且可以忽略不计，但在组件编程方面Java
相较于C#却有着不可治愈的硬伤。尤其对于从C++和Visual Basic背景过来的开发人员，C#
在这方面有着不可抵挡的魅力和诱惑。
鉴于XML Web Services在下一代企业分布式计算中的地位，我们有必要在这方面对两个
语言有一个简单的交代。在XML Web Services的操作方面，.NET平台直接在IL中间语言中的
内置XML支持使得C#与生俱来地成为下一代Web服务的首选，这是通过API集来支持Web服务的
Java所不能比的。在C#中，XML，SOAP，UDDI，WSDL等底层协议被构建成了面向开发人员的
组件，而Java中这些仍然是JAX(Java XML API)等底层协议的操作函数。当然这种局面可能
仅仅是时间问题，一个强大的高效的Web Services组件模型对Java来说并不是不可逾越的
鸿沟。
在语言标准化方面，微软也史无前例地做出了令人赞赏的动作。目前C#及.NET平台基础
构造已递交欧洲计算机制造商协会ECMA，经过标准化后的C#将可由任何厂商在任何平台上实
现其开发工具及其支持软件，这为C#的发展提供了强大的驱动力。而Java在这方面虽有动作
--JCP（Java Community Process），但无疑只能是准标准化。在组件化软件时代拥有一门
像C++一样的标准化语言，对软件界尤其是广大开发人员非常重要。
当然两个语言的全面的技术品评绝非仅仅上述几点简单的罗列比较，其后端平台(C# for .
NET, Java for J2EE)，及其编程框架的支持，各语言相关工具的实现，现有的系统基础
等等都对程序设计语言的发展产生相当的影响。从纯技术角度来讲，C#无疑较Java更具
竞争力。争吵谁抄袭谁也没有意义--技术的发展本来就是一个相互借鉴的过程。纯技术
较量也并不能决定这场论战的胜负--如果非要一决雌雄的话。软件界倒乐见竞争，经过
市场锤炼的技术才能更好地为我们服务，让我们拭目以待！
回答这个问题一定要考虑“性价比”哦！
以下文章请大家看看：：：：：：
自C#诞生之日起，关于C#与Java之间的论战便此起彼伏，至今不辍。抛却Microsoft与Sun
之间的恩怨与口角，客观地从技术上讲，C#与Java都是对传统面向对象程序设计在组件化软
件时代的革新之果，可谓殊途同归。虽说两个语言有着"90%的重叠"，但那另外"10%的较量
"也往往能够左右一个天平的方向。本文将携90%之共，论10%之异，对两个语言做纯技术品
评。文章不涉及两个语言的公司，市场等台面后的事情--虽然这往往也会影响人们对编程语
言的选择。也不预备得出谁是谁的Killer，读者应该选择谁的问题。"语言选择乃艺术而非
技术问题"，业界早有定论，无需多言。
C#和Java都提出了对传统C++艰深，晦涩的语法语义的现代改良。在语法方面，两者都
摈弃了C++中函数及其参数的const修饰，宏代换，全局变量和全局函数等许多华而不实的地
方。在继承方面，两者都采用了更易于理解和建构的单根继承和多接口实现的方案。在源代
码组织方面，都提出了声明与实现于一体的更好的逻辑封装。在类型系统方面，两个语言都
在中间语言IL或字节代码的基础上提出了映射(Reflection)这样的概念，彻底革新了传统
C++运行时类型鉴别的问题。但在大刀阔斧地对C++进行改革的同时，C#显得更为保守，它
对很多原来C++中很好的性质予以了保留，如基于栈分配的轻量级的结构类型，枚举类型，
引用（ref），输出（out），数组（params）修饰的参数传递方式等，这些在Java中都被
很可惜地丢掉了。在基本类型和单根继承的对象之间的类型统一方面C#提出的box/unbox要
比Java的包装类显得高明，效率也要好。
对C++不安全的指针及内存分配方式，C#和Java都提出了托管执行环境。效率问题是托
管执行环境一直以来令人诟病的地方，Java虚拟机（JVM）的解释执行方式曾经让很多开发
者"慢的不可忍受"。C#的JIT编译方式为C#在这块战场上赢得赞声一片，某些C#托管代码甚
至比传统C++代码都快。虽然现在各厂商实现的Java平台也都一致地采取了JIT编译方式，
但C#在这方面的比较优势非常明显--C#的目标编译语言IL从设计初始就把效率摆在了重要
的地位，而Java的字节代码的设计却有些鲁莽。托管执行环境经过几年的实践，在现代软
件界已经达成了共识，效率的牺牲换来的是高度安全的代码--当然前提是牺牲的效率必须
足够的小，至少可以忍受。值得指出的是在这里C#同样"念念不忘老一辈C++程序员"，C#允
许我们在unsafe上下文中进行指针操作。数组的索引越界检查，类型安全在C#和Java中都
被提到了相当的高度。在异常处理方面，不管从内置支持，还是从执行效率来讲，C#都较J
ava略胜一筹。
"一次编程，多处执行"是程序设计一直以来的一个诉求，尤其是在现代互联网络时代。
在跨平台方面，Java的支持和实现都是为人称道的，虽然JVM的速度仍然让人备感头疼。
而C#虽然在底层构造方面对移植性进行了充分的考虑，但至少目前还没有成熟的，经过检验
的产品。C#在跨平台方面似乎更热衷于XML Web Services互操作，而不是跨平台编程。但
C#通过其基础语言构造（CLI）对二十多种主流语言的对象级的互操作支持，又极大地提升
了C#的技术地位。和COM组件廉价地互操作也为C#挣到不少分数--保持一个兼容的体系对现
代软件工业非常重要，也是对广大开发人员负责任的表现。
面向组件无疑是当代软件开发的主流。C#对组件编程甚至到了"迷恋"的地步，这与6年
前就出道的Java不可同日而语--当然这是时代问题。C#通过属性，索引器，委派，事件，
操作符重载，特征，版本等实现了其对组件编程的第一手的支持。虽然这些在Java中都可
以通过方法，接口或者适配器来间接地实现，但软件业的历史告诉我们这无论对编程效率
或者逻辑设计都是一种极大的损伤--高级语言首先面对的是人，而不是机器。除去这些语
言层面的组件支持机制，.NET平台也为组件的配置，运行，管理等提供了一揽子解决方案
，而为组件开发量身定做的Visual Studio.NET更是令人兴奋，这都为C#的组件编程开辟了
广阔的天地。在其他技术方面Java的微弱劣势尚且可以忽略不计，但在组件编程方面Java
相较于C#却有着不可治愈的硬伤。尤其对于从C++和Visual Basic背景过来的开发人员，C#
在这方面有着不可抵挡的魅力和诱惑。
鉴于XML Web Services在下一代企业分布式计算中的地位，我们有必要在这方面对两个
语言有一个简单的交代。在XML Web Services的操作方面，.NET平台直接在IL中间语言中的
内置XML支持使得C#与生俱来地成为下一代Web服务的首选，这是通过API集来支持Web服务的
Java所不能比的。在C#中，XML，SOAP，UDDI，WSDL等底层协议被构建成了面向开发人员的
组件，而Java中这些仍然是JAX(Java XML API)等底层协议的操作函数。当然这种局面可能
仅仅是时间问题，一个强大的高效的Web Services组件模型对Java来说并不是不可逾越的
鸿沟。
在语言标准化方面，微软也史无前例地做出了令人赞赏的动作。目前C#及.NET平台基础
构造已递交欧洲计算机制造商协会ECMA，经过标准化后的C#将可由任何厂商在任何平台上实
现其开发工具及其支持软件，这为C#的发展提供了强大的驱动力。而Java在这方面虽有动作
--JCP（Java Community Process），但无疑只能是准标准化。在组件化软件时代拥有一门
像C++一样的标准化语言，对软件界尤其是广大开发人员非常重要。
当然两个语言的全面的技术品评绝非仅仅上述几点简单的罗列比较，其后端平台(C# for .
NET, Java for J2EE)，及其编程框架的支持，各语言相关工具的实现，现有的系统基础
等等都对程序设计语言的发展产生相当的影响。从纯技术角度来讲，C#无疑较Java更具
竞争力。争吵谁抄袭谁也没有意义--技术的发展本来就是一个相互借鉴的过程。纯技术
较量也并不能决定这场论战的胜负--如果非要一决雌雄的话。软件界倒乐见竞争，经过
市场锤炼的技术才能更好地为我们服务，让我们拭目以待！
