续 找骂的来了!(c++程序员敢来挑战。java中高低手都进来过瘾)

sobingman 2003-10-16 02:13:51
原文说java中高低手都来过瘾,我还没有说过瘾竟然就结了贴!可惜,于是又掏分100,再续前说。了解我的人都知道,我是欢迎反对者的,只要有理有据不进行个人攻击就行。

原文(http://expert.csdn.net/Expert/topic/2358/2358160.xml?temp=.9715387)yl0002 (yl)提到:
我是c++程序员,在这里说java的一些不足,可能我是找骂来了。(够贱的!)
我是在c++里面混的。看了一些c++之父与stl之父的访谈录,知道java的一些程序(包括sun)对c++说了很多不敬的话、吹了很多牛的话。想来java版来看看,不想没有看到扁c++的,倒看到扁java的(请看贴:臭名昭著的Java)。可笑。不知在c++版中找不找到扁c++的来(没有找过,不知找不找得到)。
本来,工具是无错的,错的是使用工具的人。(我可以用纸来杀人,但可能给你一把激光枪,你都不知怎么用)。
正确的是你对工具了解多少(该工具的缺点是什么,劣势是什么,优势是什么),用的如何熟,如何精,如何巧。
我每当看到什么delphi vs vc 或是c++ vs java之类的东西,就是看它们指出的问题(该工具的优缺点)。
(不过,好多语言好像都想和c++比一比。没办法。)
即使是你用了世界上最牛的语言(我认为:应该说没有,现在的工具都是针对一些方面有优势,一些方面有它的不足),也一样是一个傻瓜。换句话:拿着工具的傻瓜,还是傻瓜。
比如:1,我就会photoshop的操作,但还是不能做出xx公司的广告图。
2,c程序员多的是,几个写得出quake引擎的。
3,你会autocad,你给用autocad做一座与众不同的桥出来试试(如果是你建筑专业毕业,也会autocad的除外)。
我java一点都不会,也不能说出java的什么。如果java的程序或是公司要说c++什么,必须对c++有很深的了解,才能说出c++的好与坏。
对于有些人说的c++指针,c++的内存方面的说法我不同意。具体的我也不说,因为可能和我争论的人,并不了解c++。
对于java所说的平台?该是x+vm的形式。.net好像也好不到哪儿。不过我听borland总裁说:ms的阴谋是先提供.net环境,以后将nt内核换为.net。将.net做为真正的平台。
我想也许这个谁也说不好。所以sun也不能说它的平台会怎样怎样,能在ms的手心中混多久,还不一定呢?
有人可能说我是ms的什么奴隶,也许是吧,但不知,我这个奴隶是只会从ms哪儿得到好处,不付出的。什么时候不高兴,就不当它的奴隶了。(比如,sun牛了,就转java)。
大家是不是从msdos6到win3x到win95到win2000过来的,有没有一点被wintel牵着鼻子走的感觉,但也肯定从中捞到了好处(不然,你就用unix或是linux试试)。
世界没有绝对的,完美的东西。如果你要学java,最好找一个java了解很深的人,告诉你,java适合做什么,不适用于做什么。(如果这里有谁说java适用于做任何事,请回贴。)
说上面的话,是原为在该版有一些刚学java的,说了一些对java动摇的话。所以说一些我的想法。
以上是一个经常在mfc基础类混的人,第一次到java来,看到臭名昭著的Java一贴想说的。
请大家无论是骂,还是gz,都来一起回贴,请不要客气。我认为最重要是有人能和你一起争论一些东西。

**********************************************************
我的回答:
同意,而且我可以告诉你,我是从C++转到java的,并不是因为java真的好到哪里去了(事实可能正相反)而是因为java有很多商家支持,用人单位也愿意要。

其实我认为C、C++总体上比java好。
1 java的内存自动回收效率较低,可优化空间也很小。每个类生成对象时都相当new了一块内存空间,你的对象无法放在栈里,只能放在堆里,想一想你就知道这会对性能有多大影响!喜欢java的人常说C中的指针是多么多么难用可怕的东西,可是我当初用的时候一点这种感觉也没有

2 java所谓的跨多平台其实并不具有很重大的意义
就算java能很好的跨多平台,又有什么意义呢?放在一个新的平台上之前从新编辑一下又能费多大事呢?而java为了不重新编译就跨平台做了很多很多妥协,结果呢,本质上还是不能直接跨平台,而是需要做出修改,那又能比C强多少呢?

3 J2EE本身也存在巨大的问题,做出的性能牺牲实在太惨烈了,而换来的一些东西我左看右看也感觉是玩具而以,至少用C++有更好的解决办法。

所以说很多东西是商业上的抄作而已
**********************************************
反对者之一的回答:

我也是从C++转到Java上的,但是我对C++和Java的看法有所不同:

1。C++还局限在一个语言的层次,而Java已经突破了这个层次,上升到了平台的境界。在这点上,只有.NET可以相提并论。

2。C++的繁琐,对于高手来说是微不足道的。但是一个项目,尤其是大型项目,不可能所有参加的人员都是高手,这个时候,Java中提供的一些原本看来微不足道的东西,比如多线程的支持,内存管理等等,可以大大提高编码的效率和质量。同时也把高手们从帮助新手的工作中解脱出来。

3。Java的跨平台性能的意义非常重大,但是对于从来用不到跨平台开发的人或者用到跨平台开发,但是使用的平台功能只是各个平台功能交集的人来说没有意义。仅举一个简单的例子,使用C/C++和使用Java在不同平台上进行多线程应用的开发所需要付出的代价是截然不同的。从另一个方面来讲,如果知识开发桌面系统应用的话,多线程几乎是可以不考虑的。但是对于后台服务器以及中间件来说,多线程是不可避免的。而且后台服务器/中间件往往需要能够在多种操作系统中运行,这个时候,Java就体现出它巨大的威力了。当然,理论上.NET也可以,但是目前还做不到。

4。我看不到C++中有什么技术是可以和J2EE技术作比较的。CORBA/Socket的层次都太低,开发所需要的代价远比J2EE技术高得多,所以项目风险大。

5。Java的出现并不仅仅是商业炒作而已。

...全文
251 63 打赏 收藏 转发到动态 举报
写回复
用AI写文章
63 条回复
切换为时间正序
请发表友善的回复…
发表回复
pigo 2003-10-18
  • 打赏
  • 举报
回复

我不喜欢争论,争论中,更多的是以己的擅长,一味攻击别人的弱处(与语言无关,而是掌握语言的人的水平),一味回避自己的短处,走向“不是东风压倒西风,就是西风压倒东风”的局面才肯罢休。

而讨论则不同,大家不是一味攻击对方的短处,也认可对方的优点。
互通有无,兼容并包,共同进步。

对于//不想没有看到扁c++的,倒看到扁java的

一个连jdk在哪里下载都不知道的人,一上java版块就来问.net和j2ee应该选什么。

你认为这样的人的问题的争论(注意我是说争论,而不是讨论)价值如何???

很敬佩楼主, 如果你看过这里以前的那种 找骂(标题里是没有“找骂”来两个字的) 的帖子,就知道了。



//也仅仅只希望多拜读你们的高论,谁对谁错我压根不懂,但是却激起我莫大的求知欲才是最另我高兴的,而且从中我也懂了些我该学些什么,学好什么。”


强烈同意中。。。


naxin 2003-10-18
  • 打赏
  • 举报
回复
"回复人: kinggu2003(遗落的天堂) ( ) 信誉:100 2003-10-18 09:23:00 得分:0
好,我认为讨论真的有莫大的好处。
JAVA和C++没必要一定要分出个胜负,相信大家也都从讨论中找出自己的不足了吧,
这就够了,弥补自己的好处才是最重要的,SUN和MS没倒掉,那么两种语言就不该有个胜负的。
发展才是硬道理,提出缺点促进发展就要靠高手。
我也仅仅只希望多拜读你们的高论,谁对谁错我压根不懂,
但是却激起我莫大的求知欲才是最另我高兴的,而且从中我也懂了些我该学些什么,学好什么。
谢谢了!!!!
"

非常同意您的发言!
itme99 2003-10-18
  • 打赏
  • 举报
回复
既然c++有更好的办法,那为什么世界顶尖的erp厂商的产品,都是基于java或于java有莫大关系而无一是和c++有什么瓜葛的.

真是这样的啊?
kinggu2003 2003-10-18
  • 打赏
  • 举报
回复
打字打错了,弥补自己的不足才是最重要的。
kinggu2003 2003-10-18
  • 打赏
  • 举报
回复
好,我认为讨论真的有莫大的好处。
JAVA和C++没必要一定要分出个胜负,相信大家也都从讨论中找出自己的不足了吧,
这就够了,弥补自己的好处才是最重要的,SUN和MS没倒掉,那么两种语言就不该有个胜负的。
发展才是硬道理,提出缺点促进发展就要靠高手。
我也仅仅只希望多拜读你们的高论,谁对谁错我压根不懂,
但是却激起我莫大的求知欲才是最另我高兴的,而且从中我也懂了些我该学些什么,学好什么。
谢谢了!!!!
wjmmml 2003-10-18
  • 打赏
  • 举报
回复
Java技术被列为当今世界信息技术的三大要点之一,并是全球第一大通用开发平台,有数百万开发商在这个平台上开发自己的软件。除了导弹发射,Java几乎应用在信息设备的各个层面,全球仅已发货的Java手机就达到了1.2亿部。


我想,有理不在声高,呵呵,开发商是最聪明的!
Primer2002cn 2003-10-18
  • 打赏
  • 举报
回复
mark
老土豆T 2003-10-18
  • 打赏
  • 举报
回复
sobingman(丧尸)

1。对不起。我只是见你拿JBuilder与C++Builder这说,随便举个例子。。不是想讨论拿谁做S,谁做C// 事实上,我们对C/S性能几乎不考虑. S端就算考虑也是那硬件,和部署来解决问题的。 (况且,Jbuilder只是启动的时候慢(一次性全部载入内存的),真正编译运行JB不比CB慢多少。。而且CB也不是什么省油的灯。。如果去年的Broland发布会也明确讲了,JB将是他们的下一步的主打产品,即便性能非常差的JB还是被人接受了,为什么?) Server需要高性能我们当然知道,,但大家也是非常明白事理讲究效率的。所以大部分的程序跑在了高性能的服务器上。。 我一直承认java性能不如c++,也知道企业应用需要高性能(所以贴了上面的连接。)

2。 jit不会比一次编译的更好。。---这个当然。我也从来没说过他比一次编译的好。。 事实上C++编译做优化也是花时间,如果编译时间很短的,那它会执行很快(象一些存计算)。再快也是不会快过一次编译的。

3。JVM与OO没有必然联系----我也没说他们之间有联系。。上面的意思JVM 是跨平台,而Java的优点是OO和简洁 (Sorry,可能我打字比较乱,造成误解,我虽然菜但这些常识还是知道的)

4。reflection 可以对外部API调用。。当然针对是JVM的,所以我们可以在java 里能唤起一些其他应用程序。(这个我不是很懂,就算我胡说)。 可我不明白C#中也加入了relection是为了什么。

5。 其实,我发现我说了不少废话。。可能文字打多了,比较塌实。。总结下来就 2,3点。
优:语法简练,面向对象,跨平台。 缺:性能差.

sobingman(丧尸) 我觉得拿C / Java来比 在教学上有点意义,,但实际应用上,我觉得更多比较的应该是C# ,与java....我不想让人造成以为C++ 性能比java那么好,也代表.Net一定也比java好很多的误解。

ajoo 2003-10-18
  • 打赏
  • 举报
回复
c#的struct是value type, 等于是把java中的原始类型泛化。struct可以放到栈中去,大大减轻了java由于依赖gc产生的效率压力。
是复杂了语言,但是值得。而且,更可贵的是,它和c#的类型系统比较和谐地统一在一起。

比c++好的是,c#的value type是类型安全的。不会因为栈对象的销毁产生悬挂指针的问题。这是一个巨大的进步。

要是说c#比java的好处,我认为struct和将要登场的generics是最大的优势。


说几个c++的问题:
1。使用c的compile-link机制。造成语言没有全局性代码分析和优化。影响了效率。而且程序员被迫做inline这种本来是编译器的工作。
这点上,c++应该跟eiffel比比效率。

2。vtable机制。父子类指针之间的转换因为c++ vtable设计的原因,很可能编译器需要偷偷做一个指针移动(别跟我说你不懂vtable),而且,还不是永远移动,遇到0还不能移动。所以,所有的这种指针转换之间都不是简单的mov, 而是一个逻辑判断,一个加法/减法,再加上一个mov。
相比之下,java的vtable没有这个问题。永远不存在指针的移动问题。
其实,如果c++采用eiffel式的全局分析,完全可以保证一个对象只有一个vptr, 从而减少移动指针的需要。

3。如果两个类型之间不存在直接的继承关系,比如说是表亲之类,嘿嘿,编译器将不知道如何移动指针。危险!

4。兼容c造成的类型不安全。if(a=b)的错误,char c = (int)i;的错误随处可见。3[a]这种怪异语法,和古怪的函数指针语法都让人望而生畏。

5。语言倾向于Stroustrup所提到的mutable。&和*都可以重载,造成了gp程序连取一个对象的地址都困难。

6。模板没有constraint。类型检查必须要等到instantiation。类型匹配错误发生在模板代码中,往往不可辨认。concept-model作为一个非常好的面向接口编程的理念,没有语言的支持,变得很难写,也很难读。
当然,这点上java没有资格批评c++,它缺乏generics, 将要加入的GJ因为jvm的限制,也不是非常理想。

7。没有gc。作为低级语言,高级汇编语言定位的C如此决定,绝对正确。但是如果要写真正好的基于接口的程序,没有gc,不可想象。没有gc造成的使用者和提供者之间的代码耦合(比如工厂模式),不是几个smart pointer可以解决的。
而且,c/c++的最大的问题不是内存泄漏,而是悬挂指针,非法指针。c作为低级语言,自然没什么,但是如果c++把自己看成高级语言,那么语言无法防止非法指针绝对是一个shame。不要总夸耀效率,没有免费的午餐,要效率,就要付出安全,代码的可维护性,灵活性的代价。
所以,没有gc最多可以算作一个策略性的选择。有得必有失,java和c++在面对“效率”和“everything but 效率”之间的权衡上各自给出了不同的答案。值得注意的是,同样号称高效的eiffel也支持gc,所有的函数语言都支持gc, python,c#支持gc, c++的父亲Simula也支持gc(虽然支持的很不好,导致了儿子的逆反心理)

8。纠正一个误区。gc并不一定表示效率肯定低。还是要辩证地看。
对不使用动态内存的程序,gc几乎不起作用。所以效率基本没有影响
对使用内存不大的程序,或者系统内存很丰富的时候,gc等于一个内存池,因为不必要释放内存,它比new/delete, malloc/free效率还要好。
只有对内存消耗大的程序,才会有gc影响效率之说。

9。c++不支持interface的概念。事实上,在stroustrup的design and evolution一书中,可以看到,programming against interface这个理念在设计c++的时候根本未被认识到。多数c++程序员还是抱着类就是概念这样一个僵化的思维来设计程序。以至concept-model这样一个programming against interface的变体在gp中一出现居然被认为是一个了不起的新东西。

10。copy-ctor/mandatory dtor这对冤家对试图把c++程序写成更自然,更generic的企图是个打击。深拷贝的效率问题困扰着专家们,以至象RVO这样直接影响到应用语义的“优化”也被采纳了。其它的什么move ctor, 都是一个个复杂丑陋的怪物。
把对象放到栈中自然有更好的效率,但是懒惰的程序员却因此更加依赖简单的深拷贝而不是尽量共享资源。因为虽然口号叫的响,真到写程序时,谁会总写个cow玩啊?

11。meta-programming, 虽然在某些场合可以提高运行效率。但是缺点是:它不能很好地scale up到运行时。对同样的逻辑,你要用meta-programming和普通的c++代码实现两遍以覆盖编译可知和编译时不可知这两个你死我活的死对头。

12。type conversion operator, implicit constructor call, operator*, operator&, 等等,造成了c++没有必要的灵活和复杂。"say what you want"这个原则没有被忠实地执行。
c++的一些feature被很不慎重地加入语言,可能暂时得到了一部分用户的欢迎(其它的用户因为事不关己,高高挂起了),但是长远来看,复杂了语言,使gp更加困难。得不偿失。

13。自定义类型并没有完全地类似原始类型。你不能从原始类型继承(影响了gp)。而且原始类型的创建,拷贝,赋值无副作用,安全。class并没有这个保证。

14。语言对typeof,is_pointer这种meta information支持弱。造成大量程序员自己写的复杂的并且不可靠的替代品。

15。没有type inference。在使用象et这种库的时候,因为类型用来表达表达式语法树,完整写出类型非常冗长,而且等于是把同样的信息在类型和表达式两个地方重复了。这在需要存储公式对象的时候非常明显。

16。缺乏异常规格的支持。gp因为要对付可能抛出异常的可能性,就只好采取保守的做法,从代码上牺牲性能。比如说std::vector, 再比如说被推荐的一些异常安全的operator=的做法。

17。全局对象初始化的顺序无保障。如果这些对象之间有依赖关系,则产生问题。

想到哪里,说道哪里,c++先列到这里。下面说java的几个弱点:
1。原始类型和对象不统一。
2。极度依赖gc, 没有自定义的value type。
3。没有generics。至少暂时还没有
4。没有运算符重载。从c++的一个极端又跨到了另一个极端。
5。synchronization的所有house-keeping的东西都放到了Object里。虽然简化了语言,但是效率损失太大。
6。synchronized method这个东西,没有把synchronization局部化在对象内部。如果我在synchronized方法内部调用wait(), 然后外面别人来一个obj.notify()就歇菜了。应该让synchronization的数据完全封装在对象内部才对。
7。anonymous class这个东西还是语法太繁琐。
8。gc的实现不好。严格说这不是java语言的问题,是实现的问题。
9。多线程的支持并不简单好用。写并行程序仍然很麻烦,tricky。并且对线程的支持弱造成不同平台上的write once, debug everywhere的尴尬(据说concurrent ML的县城模型是最好的,可惜没有机会看到)
10。数组边界检查,动态类型检查这些东西,影响效率。在eiffel中可以turn off。但是java没有提供turn off的能力。不过这严格来说还是一个策略选择问题。不能说是java语言的问题。
11。数组协变有类型漏洞。String[]当作Object[]是不安全的。
12。不支持只读概念。比如说,如果把String[]当作readonly Object[]就补住了类型漏洞。
13。c++已经支持了override的返回类型协变。java对此没有动作。
14。一些标准jdk类库设计的比较蹩脚。比如collections,很多人指出,它没有stl优雅。这点上,Sun表现的跟c++的头脑们一样傲慢。“我们就是要设计的跟stl等不一样,也跟doug lea设计的collection不一样;UnsupportedOperationException是不可避免的。等等等等”
15。通过getXXX, setXXX的命名规则来表示bean的property也感觉有点不那么舒服。

c#了解不多,不敢乱讲话。
匪六哥 2003-10-18
  • 打赏
  • 举报
回复
神经病!!!

有那么多时间多学习一下了!

什么不是用来开发程序的,只要有市场随便你用什么!!

这社会,不是你用什么作,是别人要你怎么作,用什么作!

客户就是上帝!

效益就是目的,你随便怎么实现!

去学习了……
sobingman 2003-10-18
  • 打赏
  • 举报
回复
我的初中语文老师说:对一个问题的争论不一定会有结果,但能让争论的双方更加了解自己所争论的东西。
j4sxw 2003-10-17
  • 打赏
  • 举报
回复
楼上的兄弟.
板凳借我半个坐坐
ihyuen 2003-10-17
  • 打赏
  • 举报
回复
没有意义,个人意见!!
telenths 2003-10-17
  • 打赏
  • 举报
回复
我建议用事实说话
chanet 2003-10-17
  • 打赏
  • 举报
回复
看热闹...
loverface 2003-10-17
  • 打赏
  • 举报
回复
拉个板凳,看热闹先!
sobingman 2003-10-17
  • 打赏
  • 举报
回复
zez(思恩 为老婆多挣钱 鹤清风):
“公司无聊,闲来无事,在这瞎掰而已”,这句话怎么听怎么感觉是在说我呢,其是我还就是这么回事。

你只用C写一句话你的2000不会死,死的应该是你的程序。用C中的指针读非法地址会出现系统报错,然后系统强行kill你的进程。而在java中误用NULL值变量就可以一切顺利的正确执行下去了?答案是否,抛Exception,然后推出。如果你catch这个exception,你还可以有处理权,(C++也可以用try catch块),但那没有什么实际意义,因为这通常是因为编码错误造成的。把这种区别就称为一个软件健壮或不健壮?我没有看出本质上有什么区别,结果都是程序exit。

说到内存垃圾管理,不用说,能自动回收比手工回收要好,当然这种比较应该建立在其它参数相同的基础上。java为垃圾回收付出的性能代价值不值得?上面有仁兄说,C的问题在于有可能(注意,这是一种可能性而不是必然性)造成一块已被申请的内存没有指向其的通路。这通常是由设计(或编码)错误造成的,根本原因是忘记了释放无用的内存块。用java的话就不会出现这样的错误,旦设计错误同样会出现,比如一块资源已经用完了你却还有变量指着它(而没有用如v=null的语句),造成的结果本质上是一样的,唯一的不同在于你还有“指向其的通路”,即便你再也没有使用过这个通路。但C与java的一个重要不同就是,C++中的对象不一定要用new来从内存中申请,它可以象java中的常规数据类型(如int,float等)一样声名,他将被存于栈中,也就是说,当其所在的函数(过程)被调用完毕的时候会被自动回收(不用付出性能代价,也没有什么指针问题)。java不行,每次都要从堆里申请,这会造成内存碎片(去复习一下数据结构),对性能影响较大。此外,并不是只有高手才能用好指针,一个合格的C++程序员就应该能正确的指用它,而高手能把他用的更妙!内存泄露会造成什么恶果呢?(这一点被java书籍吓大的java程序员大都根本不知道),内存泄露会使你的程序占用更多的内存,对系统性能造成一定的影响。除非真的做得很恶,否则即便泄露,常常也泄漏不了多少,对系统造成的影响还不及使用内存自动回收带来的影响大——java很象是为了寻找一根掉在地上的火柴而用光剩下的所有火柴来照亮地面以找到它。最后,很多工具可以帮助你轻而易举的发现并找到你的C++语言程序中的内存泄露位置,你只需在之后加上一句类似java中的v = null的语句就解决了(C++中是delete v;)大家看看,这就是被java老师们说的所谓的C语言的内存泄露梦魇。(最后,C++中同样有内存自动回收工具包,使用方法与java的类似,所以不能说内存自动回收是java的专利,事实上java的内存回收机制在当初的设计上参考的就是某些C++语言的自动回收工具机制)

我不知道为什么一定要揪着我用VC开发linux上的东西,那好,我也揪着你用VJ中MS的东西开发unix上的东西,你干不干。JB可以在多平台下开发java程序,我也很喜欢它,我还不知道有什么IDE可以在多平台下开发C++程序(说不定也有),至少没有JB那么优秀的吧。但JB不java,它只是IDE,如果需要,开发出一个可以在多平台下开发C++语言的高级IDE并不比开发一个JB更难(我猜闹不好会更容易)。用VC开发的C语言程序有可能可以运行在linux下,但必须使用标准库而且需要重新编译。你所说的所谓所有java库都可以运行在任何平台上,其实是因为“所有java库”都是建立在java标准库之上(也就是j2se与j2ee,j2me库之上),如果我们要用C++的其它库,如果它也是建立在标准C++库之上的话,那么它也可以容易的移植。C比java移植只难那么一点点,就是要重新编译(难道这是一件很麻烦的事吗?),重新编译是因为要重新生成适当的机械语言,java不用重新编译,因为它里面没有机械语言,但也就因为这个,他很慢。JB固然很好,我也喜欢,可是他很慢,为什么?因为是用java编的,如果JB用C++来编,我们一定会开心的,因为只需几秒钟就可以启动了。

我再一次重申,厂商的选择不单与技术有关而且主要与商业竞争有关,就好象我最喜欢的是C而一直在做java一样。所以用厂商的的选择来评价一个语言在技术层面的优劣是毫无意义的。就好象我在这里大说java坏话,说C++的好话,可是我回到公司还是不停的学java,并鼓励别人学java用java,因为众人拾柴火焰高,如果大家全认为java好,那即便java不好,它也慢慢变的好了(而现在的事实就是这样)

totodo(dagger in my hand) :
java我也算懂些,而且也很喜欢,但还是偏爱C多一些。你的说东西有些在上面可以找到答案,但我要对你强调一点,对java的评价应该全面的看,性能与功能必须权衡对待。再有,硬件不会为你调整性能问题,在同一个硬件上性能越差的程序跑的越慢,硬件不能让他们变得一样快。最后,java从程序上优化的空间不是很大,但同样的功能C++却可以,上面也部分的说明了原因(用栈而不用堆)
hiswing 2003-10-17
  • 打赏
  • 举报
回复
JAVA在我心中是最好的.至少现在是这样.
beming 2003-10-17
  • 打赏
  • 举报
回复
沉思ing.....

不过个人还是学习jva为主.....
jspxnet 2003-10-17
  • 打赏
  • 举报
回复
我吃饭靠的就是c++ 和 java ,很好,两样都很好.两个东西差部多.没什么感觉
加载更多回复(43)

23,404

社区成员

发帖
与我相关
我的任务
社区描述
Java 非技术区
社区管理员
  • 非技术区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧