This article was nominated for deletion on 17 December 2021. The result of the discussion was keep. |
This article is rated List-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
I'm a C fan and I also like some features introduced by C++. I never wrote a Java program before. I programmed in C but used both C and C++ compilers, sometimes adding to the code features like references. However, my impression is: this article puts Java in an unfavorable light compared to C++, which might be viewed as subjective. Also, I have a personal impression. Everyone is able to produce some working program in Java (simply because of the library offered methods), while to write high quality software, both high level programming in C/C++, algorithm and data structure knowledge is needed. I have no idea how the JVM is implemented, however, I bet it began with a C/C++ compilation. And the only nice feature Java has is some metaprogramming (I prefer Lisp much more for this purpose and it also can be embaded with C/C++). Also C/C++ stands for decades (and probably will continue to stand), however, my personal impression is that Java is fading away and PHP takes it's place (my job is as a PHP programmer and I hate it, however, like before with Java, today everyone can code some program in PHP, so finding enough great C/C++ programmers is hard and only the top companies can afford it (I live in a low economy country)).
--- —Preceding unsigned comment added by 79.113.42.109 ( talk) 19:43, 1 April 2011F (UTC) This article does not compare Java and C++ programming languages.
--- —Preceding unsigned comment added by 190.175.146.75 ( talk) 11:32, 6 October 2010 (UTC) This article does not compare Java as programming language against C++. It compares Java + Java ByteCode + JVM against C++ + Native Assembler. Which is very stupid, since you can mix these anyway you want. For example you can run on other JVM's. You can compile Java code into native assembler code or C++ code into Java ByteCode. What's the point of this article? It's just wrong. If something, it should compare the languages. And for example for performance comparision, they both must be compiled into the same to be comparable.
Anonymous User: I think the person who wrote it doesn't like java, by listing all the ways java is worse then c++, and not the other way around. Also, he put extra code, such as .clone() that is not needed. — Preceding unsigned comment added by 74.95.9.18 ( talk) 01:14, 19 August 2012 (UTC)
--- —Preceding unsigned comment added by 83.254.91.82 ( talk) 20:06, 1 May 2009 (UTC)
There is no universal clone() method in Java. Although Object has a clone() method, it is protected and will throw an exception if a subclass that tries to call it does not implement the Cloneable interface. I'm going to note this in the code samples table.
—Preceding unsigned comment added by 68.35.12.123 ( talk) 07:30, 25 May 2008 (UTC)
There are some on-line articles comparing Java with C++. Some of them emphasize C++'s advantages, while others highlight Java's. Who's that guy who write "Thinking in Java"? He had a pretty comprehensive one, although it's dated now. User:Ed Poor The person you are thinking of is Bruce Eckel Mr. Shoeless ( talk) 02:20, 25 March 2020 (UTC)
–––– This is my first time editing Wiki, so please correct me if I am not doing this correctly. Just trying to help :P.
After looking at source 5, I completely disagreed on the validity of the findings of I/O operations. A difference of 5 ms is not an acceptable difference, since the bottleneck is the HDD and not the language. If the HDD is ordered to write 8 MBs, then it will write it when it can and that depends on a large amount of factors.
Furthermore, figure 6 shows completely the opposite of what the statement (Java outperforms C++ in operations such as memory allocation and file I/O) is saying. Just to test this memory allocation I quickly wrote a program to flip ~16000x16000 matrix: all ints. This matrix should theoretically take 1024 MBs. After configuring the Java to eat up 1400 MBs of RAM it agreed to do it....somewhat. For compiling (WinXP) I ran Dev-CPP4.9.9.2 with GCC 3.4.2 for mingw. For Java I used 3.2.2 Eclipse with Java 1.6.0. The matrix was read from a file and only then the program started counting.
C++ ate up 1.02 gigs and after 20 trials it printed out 1.8x seconds for each. Java's time were much less consistent. It ate up 1.01 gigs, but running times were much different. They ranged from 2.2 seconds to 2.9 seconds.
I believe that the article there is dated and invalid. 24.12.159.57 02:59, 23 May 2007 (UTC)ShadowPhoenix 24.12.159.57 02:59, 23 May 2007 (UTC)
The memory locality and allocation performance claims about Java being more efficient than C++ apear as nonsense to me, considering that when using C and C++ we have full control over these aspects. We're free to implement or use whatever efficient memory allocation system required. This is definitely not the case with Java. My guess is that those claims are only valid for casual C++ users than actual low-level coders who have an understanding of optimization issues. We can roll-out custom allocators, as well as define data structures and their relations recisely. As for the platform-independence aspects, C and C++ are actually more portable (Java only being available on specific architectures and platforms), yet I agree some architecture-specific performance tweaking can be necessary for optimal performance. The part about architecture-dependent floating point issues appears valid for C++. 66.11.179.30 23:30, 17 June 2007 (UTC)
–––––––----------
A comparison of Java to C++ should list differences. Calling those differences "advantages" or "disadvantages" of one language or the other is in most cases controversial and shows bias. Additionally, it's often impossible to argue in favor or against a specific language feature without considering the broader perspective and intent of the languages.
In the interest of maintaining a NPOV, I have reworded and moved all items from the "advantages"/"disadvantages" lists to the "differences" list. In addition, I've added a paragraph that describes the cause of many differences: differing design aims.
I urge future editors to not show bias.
-- Eelis 01:53, 2005 May 23 (UTC)
Someone deleted information about 64-bit numbers (from IP 213.94.248.38 on July 8), claiming it to be inaccurate. I have restored this information, and added a link to the 64-bit page to allow editors to vouche its authenticity, along with clearer wording. CmdrRickHunter 06:06, 2 August 2006 (UTC)
A previous edit indicated that there was dispute over whether or not C++ is better for "DSP or arithmatic heavy" operations.
I would like to add text clarifying it, but I do not feel that I have fully researched the topic. Here are my points:
Based on this, I feel the statment should be added back into the article, with clarification. However, since I am new to wikipedia, I'd at least like to see if anyone has feedback on the idea. CmdrRickHunter 21:32, 30 June 2006 (UTC)
I'm going to remove the comment that this article should be merged because I don't agree with the reasons, and the fact that editing has remained active for over 5 months and about 40 edits leads me to believe there are plenty of others to support my position. If this should be merged, I think there are enough people who have worked on this article that there should be some discussion here first. I don't want to see an overzealous and possibly inexperienced editor coming along, see the merge task as a community decision waiting to be implemented, and do the merge without discussion. CyborgTosser ( Only half the battle) 20:22, 25 Feb 2005 (UTC)
For reference, here is the original merge request as posted by Netoholic:
CyborgTosser ( Only half the battle) 20:27, 25 Feb 2005 (UTC)
This article equates resource with memory, but a resource might also be a lock that is acquired and lots of other things too.-- MarSch 15:05, 27 October 2005 (UTC)
The biggest consequence of this is that you can't have const parameter types in Java. - this is at least incredibly misleading if not incorrect. to properly explain this would require more space than this article should dedicate to the subject. someone interested in knowing more should research it further.
Destructors are essentially what enable the RAII idiom, as deallocation is done in the destructor. This means that the RAII idiom is impossible to implement properly in Java... - besides being poorly written/explained, i think this is too much depth for the article, but i think drawing a little more distinction between destructors and finalizers is appropriate.
i've updated accordingly. critique, rebut, modify at will ;) -- pfunk42 14:54, 26 December 2005 (UTC)
There is a pro-C++ (or perhaps anti-Java) POV in many of these contributions. I've lightly editted some of them to attempt NPOV. I admit to having my own bias, which I am trying not to include in the article. There are some specific points I'll address here for discussion before making additional changes to the article. Additions from 84.61.26.158 in the excepts from the article below are shown in bold italics.
goto
statements; Java does not, but its
labelled breaks provide some goto-like functionality. In fact, Java enforces
structured control flow, with the goal of code being easier to understand. That can make code distintly less readable.synchronized
mechanism, but that's not readily apparent from the statement. Deadlock could also occur in a multi-threaded C++ program that used
mutex locks to guard against contention, except that in the case of the C++ program, the release of the mutex lock is not enforced by the programming language. So it can be argued that deadlock is more likely in the multi-threaded C++ program than in the comparable Java program. --
Doug Bell
23:12, 10 January 2006 (UTC)System.runFinalizersOnExit
has been deprecated for some time. So the statement which might never happen is correct. There is no way to force finalization to occur. Even calling System.runFinalization
will not guarantee execution of the finalizers. I readded the statement and expanded the comparison of destructors and finalizers.--
Doug Bell
talk/
contrib
21:13, 11 January 2006 (UTC)In C++ we have the programming model of multiprocessing. We can create multiple multiple processes and communicate using shared memory calls. This model you can find in Apache Unix versions. If the application runs for more than a minute, multiprogramming model can be considered. The locking and uncloking problem will not be present at all. Data sharing between processes is less(low coupling when designed). It is nearly impossible in JAVA to implement this model in an efficient way. Another advantage is various platforms impose a limit on stack size when functions are called in multithreaded applications. This limitation is not applicable to this model. This is C++ way of designing and programming. :-) Jayaram Ganapathy
The article contains this table:
The different goals in the development of C++ and Java resulted in different principles and design tradeoffs between the languages.
C++ Java execution efficiency developer productivity trusts the programmer protects the programmer arbitrary memory access possible memory access only through objects concise expression explicit operation can arbitrarily override types type safety procedural and object-oriented object-oriented redefine operators meaning of operators immutable feature rich easy to use
which implies that for example execution efficiency and developer productivity are opposites. It is my understanding that C++ aims for both of these (and supports developer productivity with generic programming, unlike Java), while this table seems to say that using java allows for greater developer productivity. All other entries also suffer from POV or are simply false. I'd like some references for this table, for example from The Design and Evolution of C++. The fact Java doesn't support operator-overloading or templates, doesn't make it easier to use. What it does mean is that C++ has a far more powerful way of expressing, resulting in generic algorithms. Java doesn't protect the programmer, it forces the programmer not to do certain things. C++ protects the programmer, by providing type safety, but also providing casts. I think there is a lot of pro-Java POV in this article. Even the title (Comparison of Java to C++) is POV. MarSch 13:21, 5 March 2006 (UTC)
This section has been modified since the discussion above, but this seems to be the appropriate place to discuss its current status. Recently, I corrected a sentence in another section that said, incorrectly, that in Java function parameters were call-by-reference if the parameters were objects. This, of course, is false: in Java all function parameters are passed by value. Now, in this section, it says that Java has "reference semantics for user-defined objects", while C++ has "value-based semantics and explicit pointers". The question I have is whether this is simply the same misunderstanding of Java's parameter passing that I corrected before? The explicit calling out of "user-defined objects" suggests that it is, since in Java there is no difference between user-defined objects and built-in objects, so there definitely is some misunderstanding somewhere. On the other hand, is this some subtle semantic point? (After all, in Java there are reference types. But then, in C++ there are reference parameters as well, and so what does "value-based semantics" mean?) I'm inclined to just cut this line in the table, on the grounds that even if whatever it was meant to say is correct, it certainly doesn't convey said meaning currently. Any objections or clarifications? SlitherM 03:58, 22 March 2007 (UTC)
I've added three cleanup tags to this article.
— donhalcon ╤ 05:47, 6 March 2006 (UTC)
"C++ has more powerful syntax than Java", says the article. Right. Powerful. Precisely what, may I ask, does "powerful" mean in the context of syntax?
The whole thing seems to be like that. This article doesn't need cleanup, it needs deleting completely and rewriting from scratch, preferably by someone who doesn't prefer either language and is therefore capable of viewing them objectively. — Haeleth Talk 23:15, 16 May 2006 (UTC)
I perfectly agree with CmdrRickHunter. JAVA is a language for easy development which prevents a developer from comitting mistakes and saves him. Its language syntax is for defending for which it pays in the performance and flexibility. JAVA is not a language developed to show power. Its for fast and error free developmet with lessor effort. I would appretiate members to discuss their thoughts and learnings and we can go ahead rather than just making statements like just rework the entire page. Comparing with other languages like LISP is a wonderful idea but the members who know LISP shpuld take initiative for that.
You comments are indicative of one who is not thoroughly familiar with the Java language. Java is not C++, which I believe is the intended point of this article. It is by no means slower, less powerful, or necessarily easier to develop than C++. This article reeks of NPOV. I don't think it has to be completely rewritten, but it needs a rethink in the approach. HotBBQ 17:01, 17 April 2007 (UTC) Dear friend you cannot blindly say "it is by o means slower, less powerful etc.." We are here to discuss. If you have a point why it cannot be slower then put it down here. Convince the world. Any given day if you write a program in JAVA 99% of time a C++ equivalent will run better. 1 % they will be equal when the bench mark code is based on primitive data types. But if the bench mark is written using powerfull C++language features, the euivalent porting in JAVA in a straight forward way may not be possible at all because JAVA compromises the language power for easy programming. In this case the code written in JAVA may become twice big as C++ and performance even worse. I develop in both the languages. Jayaram Ganapathy
A partisan article like the one comparing Java and C++ has no place in Wikipedia. Its Java drum-beating is embarrassing to anyone who has dealt seriously with the range of computer languages. This piece is error-ridden and should be rewritten from the ground up.
A more general issue is, what is the point of an encylopaedia article that takes two particulars from a larger set and compares them? That is -- C++ and Java are just two of several commonly used object- (and function-) oriented languages. Where are the others? Python, LISP, Delphi, Smalltalk... these are languages that have significant industrial usage around the world. They all have thousands of advocates who can intelligently defend their particular advantages. (For example, space and atomic energy enterprises more commonly use LISP dialects than C++ or Java for their generalized applications.)
I believe that an article comparing all the major object- and function-oriented languages would be useful in this encyclopaedia. It would be difficult to write in a fair manner, but could be quite useful -- even influential -- if it were done well. —Preceding unsigned comment added by Kentfx ( talk • contribs)
Some things I believe are inaccurate, but which I'm not updating because I don't have sources for most of this.
As I understand it, most if not all Java implementations use mark and sweep garbage collection or some similar method to collect cyclical references. Certainly all the ones I've worked on do not suffer this problem. It is possible to have memory leaks, but only by making objects that will never be used again theoretically reachable if you followed the right chain of references.
This depends on the implementation of Java you are using. There is nothing in the Java Language or Virtual Machine specifications that requires the use of JNI for any native code calls. See, e.g., gcj's "CNI" implementation, which allows a native method to be implemented in C++ and directly linked to the class that uses it [1]. In this case, the overhead is significantly lower, and is in many cases as efficient as a C++ method call.
The same objection also applies to the statement "Direct access from Java to native operating system and hardware functions requires the use of the Java Native Interface."
This sentence is meaningless. It should be expanded with specific examples of why the distinction is less extensive in C++ (e.g. ability to construct a reference to fundamental types in C++ but not in Java).
Java can cause page faults too, you know. Changing "page faults and segmentation faults" to "memory access violations" might make sense.
I think this might better be phrased as "In C++ the size of an array may only be determined (using the "sizeof" operator) statically at compile time; it is impossible to determine the size of an array from a pointer to its first element." The text in the article appears to suggest that some construct like the following example would work:
void myFunction (int (&anArray)[]) { cout << sizeof(anArray) << endl; }
It won't (you'll get a compiler error in the declaration of the function, as the size of a referenced array must be known statically at compile time).
(All of the above JulesH 11:06, 17 July 2006 (UTC))
Wondering about this quote "C++ features programmer-defined operator overloading. The only overloaded operators in Java are the "+" and "+=" operators, which concatenate strings as well as performing addition." AFAIK the at least * is overloaded, i.e. it can multiply integers or reals.—The preceding unsigned comment was added by 24.201.100.166 ( talk • contribs) 05:26, 3 April 2007 (UTC)
In:
In Java, parameters are passed using pass-by-reference for non-final objects and pass-by-value for final objects.
This is wrong. The problem is that pass-by-reference and pass-by-value have different meanings in different contexts and on the relative point of view. In contrast to C++ a program variable in Java cannot hold an object but only a reference to an object. Therefore in Java there is only pass-by-value (it passes the reference as a value) but in terms of C++ Java passes objects by-reference.
Inaccuracies:
C++ is normally compiled directly to machine code which is then executed directly by the operating system
Well no, at the level we're talking here, it's executed by the processor. 212.209.45.98 ( talk) 09:35, 21 July 2010 (UTC)
I edited the section on Java arrays vs. C++ arrays, to be clearer. To JulesH, the following construct is in fact correct and works:
template<int N> void myFunction( int (&anArray)[N] ) { cout << sizeof anArray << endl; }
Another editor wrote these questions in the main article:
1. A pointer to an array is a pointer to the first element of the array, isn't it? 2. "sizeof" of a pointer to an array will produce the size of the pointer (probably four bytes)
to which the answers are:
1. No 2. You dereference the pointer before taking the sizeof.
Example:
int array[20]; int (*pointer)[20] = &array; cout << "size of array is " << sizeof *pointer << endl;
NB. I don't yet have a wiki username, my email is oldwolf@inspire.net.nz, time is 5 Sep 2006, 06:24 UTC.
Could somebody please explain why the answer to question 1 above is "No"? Why is a pointer to an array (or a reference, like &ArrayName) NOT a pointer to the first element of the array in C++?
Using int as an example:
That is why a pointer to an array is NOT a pointer to the first element of the array. You can look at the array as a pointer to the first element in the array.
OracleofTroy 20:52, 16 September 2006 (UTC)
As of now, this "encyclopaedia" material reads like a JAVA evangelist pamphlet, sorry. Totally unaceptable. —Preceding unsigned comment added by 85.138.1.15 ( talk)
I would like to add to the same. The references section is a totally biased one except the one which compares C~ also. I kindly request the administrator to remove those links and discuss over the same until an agreement on the same comes.
If you're implying that such prestigious organizations as the National Institute of Standards and Technology, Dr. Dobbs Journal, the Jet Propulsion Laboratory, and the University of Southern California produce biased work you are perhaps better off taking it up with them. derrick 23:43, 11 April 2007 (UTC)
To be very frank the institutions has nothing to do with what ever has been written. A paper presentation acceptance has to do only with the person who reviews it. There are situations when somebody has ro publish something to get a degree and the guide often closes his/her eyes. Here in wiki we don't have any such constraints :-) Jayaram Ganapathy
Hi Friend, I have jotted something in the performance section. It will trigger your thoughts. What ever optimisation JAVA can do and gain in C++ if you do the C++ way you are better off. If you code in JAVA way and the same way you map it to C++ way rather than writing in C++ then argue its difficult. Cheers( Jayaram Ganapathy)
What is the point of this article except to allow a group of people to explain why they dislike C++? This does not belong in an encyclopedia. It is original research, unsourced and POV. I am proposing this article be deleted since it seems more like a bulletin board for people who dislikes C++. Also, are we going to have articles comparing every language out there? MartinDK 12:07, 10 November 2006 (UTC)
I agree. Although it may be a popular topic in the blog-o-sphere, comparing Java to C++ is an arbitrary selection of two different programming languages with very different approaches and goals. It doesn't seem any different than trying to compare an apple and an orange. Furthermore, as the debate further below shows, it's probably impossible to provide an article that is more educational than a list of features and yet still maintains a neutral point-of-view. People can't compare languages without devolving into a debate about "which one is better", when that depends so much on what you are trying to achieve that no article can answer it for anybody, and would be nothing but opinions if it tried. I just don't think this is a good fit for Wikipedia's format and is better left to people writing blogs or hot takes on twitter. I second the notion of deleting this article.
Mr. Shoeless (
talk)
02:20, 25 March 2020 (UTC)
OK since Doug objected to the article being deleted which is fine I make the following proposal:
Dispute tags are not meant to stay on articles forever. They are meant to encourage other editors to improve the article. When that doesn't happen it is unlikely that the article will be improved and so we must consider if it needs to be deleted or what else should happen to it. It cannot simply stay the way it is now. MartinDK 09:38, 11 November 2006 (UTC)
Cut from intro:
Where is any of this expanded on, after the intro? -- Uncle Ed 20:31, 20 November 2006 (UTC)
I am totally neutral on which language is better, but I cut this:
An evaluation like this ("good support") should be sourced to an authority or advocate. -- Uncle Ed 20:38, 20 November 2006 (UTC)
Furthermore, I would like to see comments from C++ and Java programmers (published comments, that is) on why various language features are more helpful, useful, convenient or harmful, difficult, etc. I do NOT want to see an "overall" evaluation like "This language is best". Rather, on each specific aspect I want to see the tradeoffs.
Like
Keep it neutral in terms of ducking any conclusions, but let all voices speak! -- Uncle Ed 20:43, 20 November 2006 (UTC)
When I studied this I read that C++ was not suitable for passing over the internet. If a glitch in a C++ pointer to memory occurred while passing over phone lines, it could be disastrous in the receiving computer. Java, I read, was designed to be passed over the internet. Java avoided structures that if glitched could cause unending loops that would eat the receiving computer, or worse create an accidental internet virus. C++ is more powerful, but also less stable in the unstable internet environment. Java is not as powerful, but much more stable against errors. My Flatley ( talk) 05:42, 15 January 2011 (UTC)
Back in 2003 when I started making contributions to this article, I did most of my programming in Java and generally preferred Java to C++ (although I learned C++ first and had comparable amounts of experience in both languages at the time). I now do most of my programming in C++, and generally prefer C++ to Java, but I don't disagree with any of what I contributed back then, or really even with very much of the other editors' contributions at that time. In particular, I don't think the original organization of the article, with its advantages/disadvantages sections, was irreparably biased (however, I do think the current organization is better, for other reasons I will expand upon). The point of advantage/disadvantage sections in my mind was that there is overwhelming consensus on certain things that are difficult to do in each of the languages, and on certain things that are easy to do in each. There is also nearly as overwhelming a consensus on the general points that C++'s syntax is in certain aspects overly complicated (for various reasons), but that Java's simple syntax and lack of direct support for certain low-level functionality makes certain constructs that are commonly used in C++ impossible to replicate exactly and difficult to emulate.
Simply put, there are both advantages and disadvantages to Java, and there are both advantages and disadvantages to C++. Which language comes out better overall in the comparison, and indeed which language would seem to be better to an uninformed reader from the points made in the article, depends on which of the advantages/disadvantages the reader considers more important, which in turn depends on 1. what programming task they are trying to accomplish and 2. what programming style they are used to (and probably several other factors).
The main reason I think the new organization is better (and in retrospect don't think the old organization was very good) is that there are plenty of points that are relevant to the article but can't be cleanly grouped into one of the original two (advantages of each) or the expanded four (advantages/disadvantages of each) categories, namely:
And so on. What concerns me most about the article currently, and about much of the debate on the talk page, is that in the quest for "neutral point of view", it seems a lot of editors are unwilling to admit that there could be any difference that is an advantage in Java, or (although this point seems to be far less commonly disputed) an advantage in C++. Even as a C++ programmer, I have to say that some of the disputes on specific differences that were originally listed as "Advantages of Java", and the resulting discussions on some of these that found their way into the article at various times (although these have been trimmed down nicely in more recent versions), seem pretty nitpicky and don't contribute much. Again, I don't see it as much, but I would make the same point for any in-depth discussions of differences that were originally listed as "Advantages of C++". It is also concerning to me how much content has been simply cut from the article, either because someone didn't agree with it or because consensus on the topic couldn't be reached on the talk page.
I don't think it is helpful either to the readability of the article, or to getting a neutral point of view, to shy away from an advantage/disadvantage viewpoint on every single difference. I think it would be much better to take a holistic approach to neutrality, and try to point out what individual differences are considered an advantage or disadvantage by a comfortable majority of programmers, even if not an overwhelming consensus. If there is not even a comfortable majority opinion about a particular difference, then of course, I agree with not trying to push either viewpoint.
Why do I care?
Of course, let me know if you disagree. CyborgTosser ( Only half the battle) 11:54, 25 January 2007 (UTC)
One bullet in the miscellaneous section reads:
"C++ compilation features an additional textual preprocessing phase, while Java does not. Thus some users add a preprocessing phase to their build process for better support of conditional compilation."
Now, I am only really familiar with C (not so much C++), but I'm pretty sure that the two languages use the same preprocessing techniques, and I know that all C++ files must be preprocessed. Any statement in C/C++ that begins with a pound sign/hash mark (#) is a preprocessor directive. Since almost every C/C++ program at the very least includes some other file using the #include
directive, it stands to reason that the preprocessor must be run on every C/C++ source file--if only to process the includes--before it is passed to the next stage.
The statement "some users add a preprocessing phase to their build process" doesn't make any sense, because there is no way to "add a preprocessing phase" (it's always there).— Kbolino 07:15, 27 February 2007 (UTC)
Please refer some System Programming book to get a clear understanding of what is a pre processor. It has nothing to do with the house keeping tasks a build tool can do( I mean Ant). Don't comapre them. They are totally different. Don't assume/imagine better to read. :-) Jayaram Ganapathy
Dear Friend, preprocessing which I discussed above is away from the build concept you are thinking. In C++ you use utilities like make, nmake , clearmake etc.. In JAVA you have Ant, maven etc. A preprocessor is something which creates source codes for compilation. Preprocessor is not used for house keeping tasks of build where I think you imagine something like creating directory structure etc..( Jayaram Ganapathy)
Currently, the performance section has the statement "However critics claims that benchmarks are the only place that Java can exceed or match C++'s performance, and in real-world applications Java is consistently slow. [5]". Unfortunately, the citation is to someone's personal web page, which is not only not peer-reviewed, but has questionable quality. I think that a rather dramatic statement like "in real-world applications Java is consistently slow" needs a reliable source, so I'm going to delete the sentence. SlitherM 18:35, 21 March 2007 (UTC)
Hello Friends, I am the person who added the link to the page. I am very new to wiki editing. So there is a very high possibility of making mistakes in wiki standard. I apologise for the same. I use both the languages JAVA and C++. What I would like you guys to think over is on the roots of computer science theories. For JAVA you have one more level of interface between the OS and the executable program. So the load is always more. On a benchmark exercise a person can produce results to favour one party. So please don't get away with that. What ever performance a JAVA program delivers always a C++ program will deliver the same or better. The logic and design of the programs plays a mojor role in the performance. The logic used to write a JAVA program if you translate and say the C++ version is not fast it is wrong. You have to rework the same logic for appropriately using the features of C++, the specific compiler you use, the OS on which you deploy and the processor. PLEASE DON'T COMPARE THE ENTIRE JAVA PLATFORM WITH C++ LANGUAGE, COMPARE JAVA PLATFORM WITH A C++ PLATFORM( C++, Compiler, OS and the processor). I am eagerly waiting for responses. :-) Jayaram Ganapathy
Hello Friend you said "If an application is required to go through the operating system for certain performance-intensive parts of the program, it is unlikely that Java could come out ahead". You are going to the hotspot optimization concept. If something is hotspot for JAVA same is hot spot for C++ too. So even in special case of hotspot codes where you see a performance benifit possibility, in the best case a JAVA can equal C++ which is determined by the CPUs capability. So your argument is irrelevent. Before making an assumption, just think if anything giving JAVA an edge is that not possible in C++? You will get answer to most of your questions. You said " If an application is required to go through the operating system for certain performance-intensive parts of the program, it is unlikely that Java could come out ahead. " An OS's scheduling algorthm determines the performance. Can you get 100% CPU assigned to a process in all UNIX based OSes? There is always a limit put by the OS how much attention a process can get at MAX. even if CPU is available many OSes won't give. JAVA in a multiprocess model I can't see anything. So a JAVA app getting 100% in windows box giving you a throughput may perform pathetically on Slightly older solaris versions :-). I have tasted this. What ever optimisation OS undergo to support JAVA, still it will not be able to compete with C++ 1) JAVA is a language designed for easy programming. Its constructs are to prevent mistakes by programmers where as C++ provides everthing to a programmer if he is good. 2) It is interpreted 3) No control over Garbage collection 4) Operations on unsigned numbers give edge in cryptography mainly which JAVA language doesn't support. 5) Type casting from one object to another object if you knwo both objects have same kind of memory alighment and so memcopy will do in C++, but unfortumately I have to call getters and setters in JAVA. Above is a smal list of issues I tasted when I ported a big C++ apps architecture to JAVA version. I do coding in JAVA but many times I felt like coding with a handicapped language. The truth is JAVA is surviving because industry lacks god programmers and people who want to really learn things.( Jayaram Ganapathy)
Although a discussion page is probably not the place for deep technical discussions, I think statements above like "I would posit that the idea that Java byte code can possibly "exceed" the performance of native machine code is impossible" and "For JAVA you have one more level of interface between the OS and the executable program. So the load is always more." should be addressed, because they seem to keep re-occuring. These seem to make common, but incorrect assumptions about how Java and C++ are executed, and what influences performance. Briefly,
So, it is not hard to imagine that Java's performance can be as good or better than C++'s. Arguments that Java HAS to have bad performance usually Incorrectly assume that Java is interpreted, or that malloc/free is free while garbage collection is slow. SlitherM 20:59, 30 April 2007 (UTC)
Well everyone thinks JIT will improve performance and stress on the same point. Just imagine the facilities available on C++. A C++ program has a preprocessing stage. Here if because of size of a function if you are not able to inline a code you can write functios in just macros. Here we are discussing about performance only. Please don't bring in maintainance and other jargons because here we compare performance. What is there in JAVA? Macros in C/C++ save memory. A techy can understand how a #define PI 3.14 and const float PI = 3.14 will save memory. Performance also means space complexity :-). Now JIT. If you want performnace all good C++ developers will use target instruction compilation switch while compiling. So forget about JIT advantage. About GC please bring to your mind that the programmer doesn't have any control over, when it will be freed. In C++ I have full control of memory. I can say when it is allocated and when it is deallocated. If I find I need more performance because malloc/new is killing me, I can create memory pools and won't hesitate to tune my app. Also note that a minimum JVM load into memory is required for a JAVA application. That is not coming for free. At the end of the day I have complete control on my application's space complexity and time complexity.( Jayaram Ganapathy)
"In contrast, C++ allows passing objects by value to functions, which can cause significant overhead in the case that much memory must be copied or inefficient copy constructors must be called.": Negative. You can - and generally, you used to - use references and pointers in implementation of algorithms. If you copy something instead of passing reference then _it is not the same algorithm_. It is general practice to pass references and constant references to functions and methods always when it is possible. Again: "... C++ allows passing objects by value ..." does not mean "... C++ allows passing object only by value ...". I cannot see the reason of this whole paragraph. And - also - it is not important how general these practices are. The possibility is there.
Many java tutorials say everything in Java is passed by value. This is obviously true for native types. However, I view objects as being passed by reference: even though the bytes of the pointer are copied, the data itself is referenced and not copied. In C, passing a pointer to another function would be considered pass-by-value.
If you think I'm wrong, please explain on my talk page. Pcu123456789 01:57, 24 May 2007 (UTC)
I think it would be more accurate to say that primitives are passed by value and object references are passed by value. 128.113.107.41 17:38, 26 May 2007 (UTC)
The Java Language Specification states explictly that Java always uses call-by-value. Period. SlitherM 04:57, 27 May 2007 (UTC)
The problem is that "pass by value" is frequently interpreted (right or wrong) as "copy the whole object graph"
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_value which leads even this article to misleading statements like:
"Another discussion not often raised by Java programmers[weasel words] is that Java is a pass-by-value language [1], which requires much more memory copy operations[citation needed] than pointers or mutable references". —Preceding
unsigned comment added by
Davebrink (
talk •
contribs)
01:29, 5 March 2009 (UTC)
A reference in Java is a reference in Java. It is not any C++ concept and not interchangeable with any C++ concept. One similarity between references in C++ and references in Java is that we don't know (and shouldn't guess) how they are implemented, as there's nothing you can do about it, even if you find out (with a memory debugger or something). The way a reference is implemented in one implementation may or may not be the same in a different implementation. That is why talking about 'passing a reference by value' is meaningless in both languages - we don't know what the 'value' of a reference actually is in memory, and we shouldn't care; it is a meaningless concept to a user of the language. (It may have some meaning to a compiler or runtime designer, but that's not the intended audience unless we are writing about a particular compiler or JRE.) It is also equally meaningless to say 'a Java reference is a C++ pointer' or 'a Java reference is a C++ reference'. It is a separate concept - maybe somewhere between the two - but not comparable in any way that refers to 'stack', 'heap', 'address', 'memory location', 'first byte' or any other low-level or hardware concept. The languages are different abstractions of actual computer hardware and machine-code instructions; peeking behind, or guessing what's behind, the abstract scenery does not help you or the encyclopedia reader understand the language abstractions any better. -- Nigelj ( talk) 15:00, 9 December 2010 (UTC)
a=3;
foo(a);
void foo(int b) {
b=4
}
a = new Integer(3);
bar(a);
void bar(Object b) {
b = new Integer(4)
}
Now a new activation frame is created, containing the target reference (if any) and the argument values (if any), as well as enough space for the local variables and stack for the method to be invoked and any other bookkeeping information that may be required by the implementation (stack pointer, program counter, reference to previous activation frame, and the like). If there is not sufficient memory available to create such an activation frame, an StackOverflowError is thrown.
The newly created activation frame becomes the current activation frame. The effect of this is to assign the argument values to corresponding freshly created parameter variables of the method, and to make the target reference available as this, if there is a target reference. Before each argument value is assigned to its corresponding parameter variable, it is subjected to method invocation conversion (§5.3), which includes any required value set conversion (§5.1.13).
Trying to avoid favoring one these languages over the others is to miss the point, or bury the lead. The one-sentence summary of this article should be that Java is an improvement upon C++; that it is more or less an improved version of C++. That's only to be expected since Java's design had the advantage of the lessons learned from years of using C++ and other OO languages, and furthermore, C++ was handicapped by being designed as an afterthought to a non-OO, low-level language. The programming language community was able to learn a long list of lessons from C++ and and subsequent languages before the design of Java. In short, Java stands on C++'s shoulders.
Therefore, I suggest that the way to organize this page is NOT as a "C++ does this, Java does that" table that fails to show the progression from one to the other. Rather, it should be "C++ did this; Java changed it to that, and here's why... ."
Even if folks don't want the article to say that Java is an advance over C++, it is still important for the article to give the rationale behind the design choices. (And that doesn't mean giving, for each feature F, some scenarios S1..Sn where F is useful -- we can all agree that the existence of such scenarios does not constitute, by itself, sufficient reason to include feature F in a particular language, right?)
MarkAb 00:50, 11 June 2007 (UTC)
It is indeed well known that when Sun started working on Java they borrowed a lot from C++, as you said, and tried to remedy to various of its issues which were detrimental for productivity or security in specific application domains. I can certainly agree with you on that. However, Java is a higher-level language and should be seen as such; it has advantages for application programming and productivity. This can be seen as an advancement for a particular type of applications. However it would be wrong to state that C++ is not better suited for other types of applications, i.e. those more closely tied with systems programming, or those more resource constrained. Java was never intended to generally deprecate C++ and such a belief would be a false impression. Similarily, C, a predecessor of C++ still remains widely used for certain domains such as low-level kernel programming and is not about to die. 66.11.179.30 00:52, 18 June 2007 (UTC)
It is a myth that C++ fits as a low level language than High level language or JAVA is still a higher level language than C++. JAVA is a language which sticks only to Object Oriented Model. C++ is a general purpose language which is suitable for a superset of programming models. If you compare C++ and JAVA language features for OOP programming you can find a 1 to 1 mapping for the features. Actually in C++ better OOP is possible. The key difference is JAVA don't allow non-OOP programming where as C++ allows. In that way JAVA defences the programmer but the cost is paid by real good programmers is the flexibility.
As a language C++ needs lesser number of code to do a logic than JAVA. The productivity of JAVA comes from the IDE and the JSDK API. But the same library is ported to C++ the number of lines required will be less. Please note the multiple inheritance where code can be shared. There the common argument is diamond of death. But a good designer will store the data smartly inside those classes which inherit from the common ancestor. So as language C++ is a superset of JAVA for me. As of today many open source libraries are available for C++ for multithreading, cryptography etc which are provided in JSDK. The only point is they are not from a single vendor. May be a vendor like SUN can provide CPPSDK. C++ language is still evolving and the version C++ 0X is awaited. If you compare JAVA EJB's with C++ equivalents, you have Tuxedo ATMI and CORBA from BEA systems. You have to pay for that, which is rock solid. Here the inout parameters are allowed. But in EJB if you want to return multiple objects then you have to pack them inside a vector. See it is still not matuared and the additional overload. If microsoft extends support to their COM/COM++/DCOM to Unix platforms that will literally be a revelution the industry. As you can see the clock speeds of CPU are not getting increased. Now multi core systems are available but the scalability is not linear. The huge business systems which are built and runs on multiple geogrphic regions will impose strict time lines. Also the volume of business increase is faster than the speed with which hardware speed increase Jayaram Ganapathy
One thing that seems to be missing from this article is anything objectively measuring the relative market share and/or developer use of these two languages. Does anybody know of any studies that could be cited that indicate whether Java is really replacing C++? 69.81.190.216 22:16, 18 June 2007 (UTC)
This turned up in the article today. "Starting with Java version 1.5 default values for functions is allowed." I have never heard this is possible, nor can I find anything that indicates that it can. So I will delete it in a few days unless a reference turns up. Esben ( talk) 15:00, 19 December 2007 (UTC)
One of C++'s greatest features is generic programming, and is underdocumented here. The article makes it look as if Java is just slightly less powerful in this regard, but actually it is VASTLY underpowered. Concepts - the bread and butter of generic programming - can only be approximated with bound generics, which put some serious constraints on the genericity (all generics parameters have to inherit from the bound type). Otherwise, things like:
class test < T > { void foo(T t) { t.do_something(); } }
just won't work in a type-safe manner. Generic programming is also the area where operator overloading really starts to make sense. There are many examples available from Boost that could highlight this. -- 80.121.69.21 ( talk) 10:46, 12 May 2008 (UTC)
Is it just me, or has this site been hacked?
http://www.cellperformance.com/
It redirects to a fraudulent (viral) site:
http://anti-virus-secure-scanner.com/
Also, it seems the site's lease is going to expire soon anyways:
http://whois.domaintools.com/cellperformance.com
This will be posted in each of the following discussions at: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C++ http://en.wikipedia.org/wiki/Aliasing_(computing) http://en.wikipedia.org/wiki/Restrict
76.64.33.246 ( talk) 06:20, 2 January 2009 (UTC)
I think this article's organization is unwieldy. • Some differences' placements are confusing. Why are unsigned arithmetic, operator overloading, and bounds checking considered "design goals"? Also, the difference between semantics and syntax here is unclear. Shouldn't pointers be in syntax? And shouldn't generics, templates, multiple inheritance, and multithreading support only be in language features? Differences like built-in support might be hard to place properly since they're language features in Java but library features in C++. • Why does the article switch between bullet points and a table format? Was this intentional? If not, I'd be happy to move the bullet points into a table format. If someone could explain this organization to me, then that would be great, and perhaps we could explain it in the intro. Otherwise, does anyone object to me trying to reorganize it? I can place my suggestions for difference categorization here first. dmyersturnbull ⇒ talk 21:42, 22 May 2009 (UTC)
I think there are a few points that are either glossed over or not discussed thoroughly enough in this article. Here's a list of what I think could be covered better:
I'm not trying to advocate Java over C++. I like both languages, and each has its strengths and weaknesses, but Java's main strengths seem to be mentioned only in passing in this article. -- Schapel ( talk) 13:56, 13 May 2011 (UTC)
Reading this article gave me quite a bit of pleasure, imagining how passionate some people can be about programming languages. The article itself is like a magnifying glass left on the top of a table filled with the history of programming languages - without the big picture it is hard to understand the details. There is no point in making a comparison between C++ and Java because the languages are not in competition, only people can do this silliness. A more neutral way to present the whole topic is by language feature, say, how do I declare objects, initialize them, pass them to methods, manage their allocation details and performance characteristics, etc. And not talk just about C++ and Java. Talk about SNOBOL, talk about Ada, talk about PROLOG. Stop living in the 21st century. Talk about the PDP/11, about Multics, about VAX/VMS, about the z80. Get serious. And take that object out of your pocket. 72.195.132.8 ( talk) 01:12, 1 July 2012 (UTC)jcb
I have added more info and deleted unneeded statements. There is huge bias on java. — Preceding unsigned comment added by 74.95.9.18 ( talk) 01:58, 19 August 2012 (UTC)
It says "* All objects are allocated on the heap." Only to then backtrack a few sentences later to explain how this is actually not true. The whole section is actually quite sad, and does not reflect the massive care that must have gone into it, judging from the size of the discussion page. 2620:0:1046:0:BE30:5BFF:FEE2:AFCF ( talk) 19:35, 4 October 2012 (UTC)
It is said that "HotSpot can remove bounds checking". But as far as I understand it's only an optimization technique which sometimes remove bound checking but not suppress it totally. Xavier Combelle ( talk) 17:33, 22 July 2013 (UTC)
If we're going to say that "Various aspects of the language are covered by patents and copyrights held by Oracle.", then we need a cite to back it up. Oracle_v._Google says the opposite, that provided they avoid copying code, Google can implement Java (and all its APIs) even over Oracle's objections. http://www.javaworld.com/jw-10-1997/jw-10-lawsuit.html says "the complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract." That long list does not include copyrights or patents. If we're wildly speculating, http://communities.mentor.com/community/cs/archives/cxx-abi-dev/msg01295.html is a list of possible patents over C++ implementations (not really from a reliable source) and if GCC's C++ implementation violates any of them, so almost certainly does GCC's Java implementation, as they share an ABI... and IBM and Microsoft are the corporate names on those patents, not Oracle.-- Prosfilaes ( talk) 08:24, 27 October 2013 (UTC)
Guys/Gals,
Java does not support multiple inheritance. <---- note that there's a period at the end of that sentence
I call your attention to: http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
Specifically, the fact that that article begins by stating that *implementation* is what is being inherited, NOT TO BE CONFUSED with subtyping:
http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Inheritance_vs_subtyping
Anyone who understands multiple inheritance and its problem(s) would know quite well that Java does not support multiple inheritance, and the creators of Java were very vocal and open about their reasons for excluding multiple inheritance from the Java language spec.
Aquishix ( talk) 12:19, 10 February 2014 (UTC)
I believe there is an error in the generics vs. templates comparison section.
It says (as of 11/18/2015):
C++ Templates | Java Generics |
---|---|
Templates can be specialized—a separate implementation could be provided for a particular template parameter. | Generics cannot be specialized. |
The below program shows an example of specializing a generic method for a specific template parameter. The "myCount" method is specialized for subclasses (inclusive) of Character. Is this not "providing a separate implementation for a particular template parameter"? It seems to precisely match the definition of "Explicit template specialization" given here: Template (programming)#Explicit template specialization
import java.util.*;
public class Test {
static <T> int myCount (Iterator<T> iterator, T val)
{
int ret = 0;
while (iterator.hasNext()) {
T entry = iterator.next();
if (entry.equals(val)) ++ret;
}
return ret;
}
static <T extends Character> int myCount (Iterator<T> iterator, T val)
{
System.out.println("weirdcount");
int ret = 0;
while (iterator.hasNext()) {
T entry = iterator.next();
if (entry.equals(val)) ++ret;
}
return ret*3;
}
public static void main (String[] args) {
List<Integer> nums = new ArrayList<>(Arrays.asList(1,2,3,3,3,4,5,2,1));
int count = myCount(nums.iterator(), 3);
System.out.println(count);
List<Character> characters =
new ArrayList<>(Arrays.asList('a','b','c','d','e','a','b'));
int count2 = myCount(characters.iterator(), 'a');
System.out.println(count2);
}
}
Thanks, Vancan1ty ( talk) 04:35, 19 November 2015 (UTC)
I think the article should also state that C++ nested classes differ from Java inner classes. C++ nested classes are kinda like a static class in Java and can not access fields in the outer class unless they are static (C++11)
Hello fellow Wikipedians,
I have just modified one external link on Comparison of Java and C++. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 16:29, 11 August 2017 (UTC)
This article was nominated for deletion on 17 December 2021. The result of the discussion was keep. |
This article is rated List-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||||||||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
I'm a C fan and I also like some features introduced by C++. I never wrote a Java program before. I programmed in C but used both C and C++ compilers, sometimes adding to the code features like references. However, my impression is: this article puts Java in an unfavorable light compared to C++, which might be viewed as subjective. Also, I have a personal impression. Everyone is able to produce some working program in Java (simply because of the library offered methods), while to write high quality software, both high level programming in C/C++, algorithm and data structure knowledge is needed. I have no idea how the JVM is implemented, however, I bet it began with a C/C++ compilation. And the only nice feature Java has is some metaprogramming (I prefer Lisp much more for this purpose and it also can be embaded with C/C++). Also C/C++ stands for decades (and probably will continue to stand), however, my personal impression is that Java is fading away and PHP takes it's place (my job is as a PHP programmer and I hate it, however, like before with Java, today everyone can code some program in PHP, so finding enough great C/C++ programmers is hard and only the top companies can afford it (I live in a low economy country)).
--- —Preceding unsigned comment added by 79.113.42.109 ( talk) 19:43, 1 April 2011F (UTC) This article does not compare Java and C++ programming languages.
--- —Preceding unsigned comment added by 190.175.146.75 ( talk) 11:32, 6 October 2010 (UTC) This article does not compare Java as programming language against C++. It compares Java + Java ByteCode + JVM against C++ + Native Assembler. Which is very stupid, since you can mix these anyway you want. For example you can run on other JVM's. You can compile Java code into native assembler code or C++ code into Java ByteCode. What's the point of this article? It's just wrong. If something, it should compare the languages. And for example for performance comparision, they both must be compiled into the same to be comparable.
Anonymous User: I think the person who wrote it doesn't like java, by listing all the ways java is worse then c++, and not the other way around. Also, he put extra code, such as .clone() that is not needed. — Preceding unsigned comment added by 74.95.9.18 ( talk) 01:14, 19 August 2012 (UTC)
--- —Preceding unsigned comment added by 83.254.91.82 ( talk) 20:06, 1 May 2009 (UTC)
There is no universal clone() method in Java. Although Object has a clone() method, it is protected and will throw an exception if a subclass that tries to call it does not implement the Cloneable interface. I'm going to note this in the code samples table.
—Preceding unsigned comment added by 68.35.12.123 ( talk) 07:30, 25 May 2008 (UTC)
There are some on-line articles comparing Java with C++. Some of them emphasize C++'s advantages, while others highlight Java's. Who's that guy who write "Thinking in Java"? He had a pretty comprehensive one, although it's dated now. User:Ed Poor The person you are thinking of is Bruce Eckel Mr. Shoeless ( talk) 02:20, 25 March 2020 (UTC)
–––– This is my first time editing Wiki, so please correct me if I am not doing this correctly. Just trying to help :P.
After looking at source 5, I completely disagreed on the validity of the findings of I/O operations. A difference of 5 ms is not an acceptable difference, since the bottleneck is the HDD and not the language. If the HDD is ordered to write 8 MBs, then it will write it when it can and that depends on a large amount of factors.
Furthermore, figure 6 shows completely the opposite of what the statement (Java outperforms C++ in operations such as memory allocation and file I/O) is saying. Just to test this memory allocation I quickly wrote a program to flip ~16000x16000 matrix: all ints. This matrix should theoretically take 1024 MBs. After configuring the Java to eat up 1400 MBs of RAM it agreed to do it....somewhat. For compiling (WinXP) I ran Dev-CPP4.9.9.2 with GCC 3.4.2 for mingw. For Java I used 3.2.2 Eclipse with Java 1.6.0. The matrix was read from a file and only then the program started counting.
C++ ate up 1.02 gigs and after 20 trials it printed out 1.8x seconds for each. Java's time were much less consistent. It ate up 1.01 gigs, but running times were much different. They ranged from 2.2 seconds to 2.9 seconds.
I believe that the article there is dated and invalid. 24.12.159.57 02:59, 23 May 2007 (UTC)ShadowPhoenix 24.12.159.57 02:59, 23 May 2007 (UTC)
The memory locality and allocation performance claims about Java being more efficient than C++ apear as nonsense to me, considering that when using C and C++ we have full control over these aspects. We're free to implement or use whatever efficient memory allocation system required. This is definitely not the case with Java. My guess is that those claims are only valid for casual C++ users than actual low-level coders who have an understanding of optimization issues. We can roll-out custom allocators, as well as define data structures and their relations recisely. As for the platform-independence aspects, C and C++ are actually more portable (Java only being available on specific architectures and platforms), yet I agree some architecture-specific performance tweaking can be necessary for optimal performance. The part about architecture-dependent floating point issues appears valid for C++. 66.11.179.30 23:30, 17 June 2007 (UTC)
–––––––----------
A comparison of Java to C++ should list differences. Calling those differences "advantages" or "disadvantages" of one language or the other is in most cases controversial and shows bias. Additionally, it's often impossible to argue in favor or against a specific language feature without considering the broader perspective and intent of the languages.
In the interest of maintaining a NPOV, I have reworded and moved all items from the "advantages"/"disadvantages" lists to the "differences" list. In addition, I've added a paragraph that describes the cause of many differences: differing design aims.
I urge future editors to not show bias.
-- Eelis 01:53, 2005 May 23 (UTC)
Someone deleted information about 64-bit numbers (from IP 213.94.248.38 on July 8), claiming it to be inaccurate. I have restored this information, and added a link to the 64-bit page to allow editors to vouche its authenticity, along with clearer wording. CmdrRickHunter 06:06, 2 August 2006 (UTC)
A previous edit indicated that there was dispute over whether or not C++ is better for "DSP or arithmatic heavy" operations.
I would like to add text clarifying it, but I do not feel that I have fully researched the topic. Here are my points:
Based on this, I feel the statment should be added back into the article, with clarification. However, since I am new to wikipedia, I'd at least like to see if anyone has feedback on the idea. CmdrRickHunter 21:32, 30 June 2006 (UTC)
I'm going to remove the comment that this article should be merged because I don't agree with the reasons, and the fact that editing has remained active for over 5 months and about 40 edits leads me to believe there are plenty of others to support my position. If this should be merged, I think there are enough people who have worked on this article that there should be some discussion here first. I don't want to see an overzealous and possibly inexperienced editor coming along, see the merge task as a community decision waiting to be implemented, and do the merge without discussion. CyborgTosser ( Only half the battle) 20:22, 25 Feb 2005 (UTC)
For reference, here is the original merge request as posted by Netoholic:
CyborgTosser ( Only half the battle) 20:27, 25 Feb 2005 (UTC)
This article equates resource with memory, but a resource might also be a lock that is acquired and lots of other things too.-- MarSch 15:05, 27 October 2005 (UTC)
The biggest consequence of this is that you can't have const parameter types in Java. - this is at least incredibly misleading if not incorrect. to properly explain this would require more space than this article should dedicate to the subject. someone interested in knowing more should research it further.
Destructors are essentially what enable the RAII idiom, as deallocation is done in the destructor. This means that the RAII idiom is impossible to implement properly in Java... - besides being poorly written/explained, i think this is too much depth for the article, but i think drawing a little more distinction between destructors and finalizers is appropriate.
i've updated accordingly. critique, rebut, modify at will ;) -- pfunk42 14:54, 26 December 2005 (UTC)
There is a pro-C++ (or perhaps anti-Java) POV in many of these contributions. I've lightly editted some of them to attempt NPOV. I admit to having my own bias, which I am trying not to include in the article. There are some specific points I'll address here for discussion before making additional changes to the article. Additions from 84.61.26.158 in the excepts from the article below are shown in bold italics.
goto
statements; Java does not, but its
labelled breaks provide some goto-like functionality. In fact, Java enforces
structured control flow, with the goal of code being easier to understand. That can make code distintly less readable.synchronized
mechanism, but that's not readily apparent from the statement. Deadlock could also occur in a multi-threaded C++ program that used
mutex locks to guard against contention, except that in the case of the C++ program, the release of the mutex lock is not enforced by the programming language. So it can be argued that deadlock is more likely in the multi-threaded C++ program than in the comparable Java program. --
Doug Bell
23:12, 10 January 2006 (UTC)System.runFinalizersOnExit
has been deprecated for some time. So the statement which might never happen is correct. There is no way to force finalization to occur. Even calling System.runFinalization
will not guarantee execution of the finalizers. I readded the statement and expanded the comparison of destructors and finalizers.--
Doug Bell
talk/
contrib
21:13, 11 January 2006 (UTC)In C++ we have the programming model of multiprocessing. We can create multiple multiple processes and communicate using shared memory calls. This model you can find in Apache Unix versions. If the application runs for more than a minute, multiprogramming model can be considered. The locking and uncloking problem will not be present at all. Data sharing between processes is less(low coupling when designed). It is nearly impossible in JAVA to implement this model in an efficient way. Another advantage is various platforms impose a limit on stack size when functions are called in multithreaded applications. This limitation is not applicable to this model. This is C++ way of designing and programming. :-) Jayaram Ganapathy
The article contains this table:
The different goals in the development of C++ and Java resulted in different principles and design tradeoffs between the languages.
C++ Java execution efficiency developer productivity trusts the programmer protects the programmer arbitrary memory access possible memory access only through objects concise expression explicit operation can arbitrarily override types type safety procedural and object-oriented object-oriented redefine operators meaning of operators immutable feature rich easy to use
which implies that for example execution efficiency and developer productivity are opposites. It is my understanding that C++ aims for both of these (and supports developer productivity with generic programming, unlike Java), while this table seems to say that using java allows for greater developer productivity. All other entries also suffer from POV or are simply false. I'd like some references for this table, for example from The Design and Evolution of C++. The fact Java doesn't support operator-overloading or templates, doesn't make it easier to use. What it does mean is that C++ has a far more powerful way of expressing, resulting in generic algorithms. Java doesn't protect the programmer, it forces the programmer not to do certain things. C++ protects the programmer, by providing type safety, but also providing casts. I think there is a lot of pro-Java POV in this article. Even the title (Comparison of Java to C++) is POV. MarSch 13:21, 5 March 2006 (UTC)
This section has been modified since the discussion above, but this seems to be the appropriate place to discuss its current status. Recently, I corrected a sentence in another section that said, incorrectly, that in Java function parameters were call-by-reference if the parameters were objects. This, of course, is false: in Java all function parameters are passed by value. Now, in this section, it says that Java has "reference semantics for user-defined objects", while C++ has "value-based semantics and explicit pointers". The question I have is whether this is simply the same misunderstanding of Java's parameter passing that I corrected before? The explicit calling out of "user-defined objects" suggests that it is, since in Java there is no difference between user-defined objects and built-in objects, so there definitely is some misunderstanding somewhere. On the other hand, is this some subtle semantic point? (After all, in Java there are reference types. But then, in C++ there are reference parameters as well, and so what does "value-based semantics" mean?) I'm inclined to just cut this line in the table, on the grounds that even if whatever it was meant to say is correct, it certainly doesn't convey said meaning currently. Any objections or clarifications? SlitherM 03:58, 22 March 2007 (UTC)
I've added three cleanup tags to this article.
— donhalcon ╤ 05:47, 6 March 2006 (UTC)
"C++ has more powerful syntax than Java", says the article. Right. Powerful. Precisely what, may I ask, does "powerful" mean in the context of syntax?
The whole thing seems to be like that. This article doesn't need cleanup, it needs deleting completely and rewriting from scratch, preferably by someone who doesn't prefer either language and is therefore capable of viewing them objectively. — Haeleth Talk 23:15, 16 May 2006 (UTC)
I perfectly agree with CmdrRickHunter. JAVA is a language for easy development which prevents a developer from comitting mistakes and saves him. Its language syntax is for defending for which it pays in the performance and flexibility. JAVA is not a language developed to show power. Its for fast and error free developmet with lessor effort. I would appretiate members to discuss their thoughts and learnings and we can go ahead rather than just making statements like just rework the entire page. Comparing with other languages like LISP is a wonderful idea but the members who know LISP shpuld take initiative for that.
You comments are indicative of one who is not thoroughly familiar with the Java language. Java is not C++, which I believe is the intended point of this article. It is by no means slower, less powerful, or necessarily easier to develop than C++. This article reeks of NPOV. I don't think it has to be completely rewritten, but it needs a rethink in the approach. HotBBQ 17:01, 17 April 2007 (UTC) Dear friend you cannot blindly say "it is by o means slower, less powerful etc.." We are here to discuss. If you have a point why it cannot be slower then put it down here. Convince the world. Any given day if you write a program in JAVA 99% of time a C++ equivalent will run better. 1 % they will be equal when the bench mark code is based on primitive data types. But if the bench mark is written using powerfull C++language features, the euivalent porting in JAVA in a straight forward way may not be possible at all because JAVA compromises the language power for easy programming. In this case the code written in JAVA may become twice big as C++ and performance even worse. I develop in both the languages. Jayaram Ganapathy
A partisan article like the one comparing Java and C++ has no place in Wikipedia. Its Java drum-beating is embarrassing to anyone who has dealt seriously with the range of computer languages. This piece is error-ridden and should be rewritten from the ground up.
A more general issue is, what is the point of an encylopaedia article that takes two particulars from a larger set and compares them? That is -- C++ and Java are just two of several commonly used object- (and function-) oriented languages. Where are the others? Python, LISP, Delphi, Smalltalk... these are languages that have significant industrial usage around the world. They all have thousands of advocates who can intelligently defend their particular advantages. (For example, space and atomic energy enterprises more commonly use LISP dialects than C++ or Java for their generalized applications.)
I believe that an article comparing all the major object- and function-oriented languages would be useful in this encyclopaedia. It would be difficult to write in a fair manner, but could be quite useful -- even influential -- if it were done well. —Preceding unsigned comment added by Kentfx ( talk • contribs)
Some things I believe are inaccurate, but which I'm not updating because I don't have sources for most of this.
As I understand it, most if not all Java implementations use mark and sweep garbage collection or some similar method to collect cyclical references. Certainly all the ones I've worked on do not suffer this problem. It is possible to have memory leaks, but only by making objects that will never be used again theoretically reachable if you followed the right chain of references.
This depends on the implementation of Java you are using. There is nothing in the Java Language or Virtual Machine specifications that requires the use of JNI for any native code calls. See, e.g., gcj's "CNI" implementation, which allows a native method to be implemented in C++ and directly linked to the class that uses it [1]. In this case, the overhead is significantly lower, and is in many cases as efficient as a C++ method call.
The same objection also applies to the statement "Direct access from Java to native operating system and hardware functions requires the use of the Java Native Interface."
This sentence is meaningless. It should be expanded with specific examples of why the distinction is less extensive in C++ (e.g. ability to construct a reference to fundamental types in C++ but not in Java).
Java can cause page faults too, you know. Changing "page faults and segmentation faults" to "memory access violations" might make sense.
I think this might better be phrased as "In C++ the size of an array may only be determined (using the "sizeof" operator) statically at compile time; it is impossible to determine the size of an array from a pointer to its first element." The text in the article appears to suggest that some construct like the following example would work:
void myFunction (int (&anArray)[]) { cout << sizeof(anArray) << endl; }
It won't (you'll get a compiler error in the declaration of the function, as the size of a referenced array must be known statically at compile time).
(All of the above JulesH 11:06, 17 July 2006 (UTC))
Wondering about this quote "C++ features programmer-defined operator overloading. The only overloaded operators in Java are the "+" and "+=" operators, which concatenate strings as well as performing addition." AFAIK the at least * is overloaded, i.e. it can multiply integers or reals.—The preceding unsigned comment was added by 24.201.100.166 ( talk • contribs) 05:26, 3 April 2007 (UTC)
In:
In Java, parameters are passed using pass-by-reference for non-final objects and pass-by-value for final objects.
This is wrong. The problem is that pass-by-reference and pass-by-value have different meanings in different contexts and on the relative point of view. In contrast to C++ a program variable in Java cannot hold an object but only a reference to an object. Therefore in Java there is only pass-by-value (it passes the reference as a value) but in terms of C++ Java passes objects by-reference.
Inaccuracies:
C++ is normally compiled directly to machine code which is then executed directly by the operating system
Well no, at the level we're talking here, it's executed by the processor. 212.209.45.98 ( talk) 09:35, 21 July 2010 (UTC)
I edited the section on Java arrays vs. C++ arrays, to be clearer. To JulesH, the following construct is in fact correct and works:
template<int N> void myFunction( int (&anArray)[N] ) { cout << sizeof anArray << endl; }
Another editor wrote these questions in the main article:
1. A pointer to an array is a pointer to the first element of the array, isn't it? 2. "sizeof" of a pointer to an array will produce the size of the pointer (probably four bytes)
to which the answers are:
1. No 2. You dereference the pointer before taking the sizeof.
Example:
int array[20]; int (*pointer)[20] = &array; cout << "size of array is " << sizeof *pointer << endl;
NB. I don't yet have a wiki username, my email is oldwolf@inspire.net.nz, time is 5 Sep 2006, 06:24 UTC.
Could somebody please explain why the answer to question 1 above is "No"? Why is a pointer to an array (or a reference, like &ArrayName) NOT a pointer to the first element of the array in C++?
Using int as an example:
That is why a pointer to an array is NOT a pointer to the first element of the array. You can look at the array as a pointer to the first element in the array.
OracleofTroy 20:52, 16 September 2006 (UTC)
As of now, this "encyclopaedia" material reads like a JAVA evangelist pamphlet, sorry. Totally unaceptable. —Preceding unsigned comment added by 85.138.1.15 ( talk)
I would like to add to the same. The references section is a totally biased one except the one which compares C~ also. I kindly request the administrator to remove those links and discuss over the same until an agreement on the same comes.
If you're implying that such prestigious organizations as the National Institute of Standards and Technology, Dr. Dobbs Journal, the Jet Propulsion Laboratory, and the University of Southern California produce biased work you are perhaps better off taking it up with them. derrick 23:43, 11 April 2007 (UTC)
To be very frank the institutions has nothing to do with what ever has been written. A paper presentation acceptance has to do only with the person who reviews it. There are situations when somebody has ro publish something to get a degree and the guide often closes his/her eyes. Here in wiki we don't have any such constraints :-) Jayaram Ganapathy
Hi Friend, I have jotted something in the performance section. It will trigger your thoughts. What ever optimisation JAVA can do and gain in C++ if you do the C++ way you are better off. If you code in JAVA way and the same way you map it to C++ way rather than writing in C++ then argue its difficult. Cheers( Jayaram Ganapathy)
What is the point of this article except to allow a group of people to explain why they dislike C++? This does not belong in an encyclopedia. It is original research, unsourced and POV. I am proposing this article be deleted since it seems more like a bulletin board for people who dislikes C++. Also, are we going to have articles comparing every language out there? MartinDK 12:07, 10 November 2006 (UTC)
I agree. Although it may be a popular topic in the blog-o-sphere, comparing Java to C++ is an arbitrary selection of two different programming languages with very different approaches and goals. It doesn't seem any different than trying to compare an apple and an orange. Furthermore, as the debate further below shows, it's probably impossible to provide an article that is more educational than a list of features and yet still maintains a neutral point-of-view. People can't compare languages without devolving into a debate about "which one is better", when that depends so much on what you are trying to achieve that no article can answer it for anybody, and would be nothing but opinions if it tried. I just don't think this is a good fit for Wikipedia's format and is better left to people writing blogs or hot takes on twitter. I second the notion of deleting this article.
Mr. Shoeless (
talk)
02:20, 25 March 2020 (UTC)
OK since Doug objected to the article being deleted which is fine I make the following proposal:
Dispute tags are not meant to stay on articles forever. They are meant to encourage other editors to improve the article. When that doesn't happen it is unlikely that the article will be improved and so we must consider if it needs to be deleted or what else should happen to it. It cannot simply stay the way it is now. MartinDK 09:38, 11 November 2006 (UTC)
Cut from intro:
Where is any of this expanded on, after the intro? -- Uncle Ed 20:31, 20 November 2006 (UTC)
I am totally neutral on which language is better, but I cut this:
An evaluation like this ("good support") should be sourced to an authority or advocate. -- Uncle Ed 20:38, 20 November 2006 (UTC)
Furthermore, I would like to see comments from C++ and Java programmers (published comments, that is) on why various language features are more helpful, useful, convenient or harmful, difficult, etc. I do NOT want to see an "overall" evaluation like "This language is best". Rather, on each specific aspect I want to see the tradeoffs.
Like
Keep it neutral in terms of ducking any conclusions, but let all voices speak! -- Uncle Ed 20:43, 20 November 2006 (UTC)
When I studied this I read that C++ was not suitable for passing over the internet. If a glitch in a C++ pointer to memory occurred while passing over phone lines, it could be disastrous in the receiving computer. Java, I read, was designed to be passed over the internet. Java avoided structures that if glitched could cause unending loops that would eat the receiving computer, or worse create an accidental internet virus. C++ is more powerful, but also less stable in the unstable internet environment. Java is not as powerful, but much more stable against errors. My Flatley ( talk) 05:42, 15 January 2011 (UTC)
Back in 2003 when I started making contributions to this article, I did most of my programming in Java and generally preferred Java to C++ (although I learned C++ first and had comparable amounts of experience in both languages at the time). I now do most of my programming in C++, and generally prefer C++ to Java, but I don't disagree with any of what I contributed back then, or really even with very much of the other editors' contributions at that time. In particular, I don't think the original organization of the article, with its advantages/disadvantages sections, was irreparably biased (however, I do think the current organization is better, for other reasons I will expand upon). The point of advantage/disadvantage sections in my mind was that there is overwhelming consensus on certain things that are difficult to do in each of the languages, and on certain things that are easy to do in each. There is also nearly as overwhelming a consensus on the general points that C++'s syntax is in certain aspects overly complicated (for various reasons), but that Java's simple syntax and lack of direct support for certain low-level functionality makes certain constructs that are commonly used in C++ impossible to replicate exactly and difficult to emulate.
Simply put, there are both advantages and disadvantages to Java, and there are both advantages and disadvantages to C++. Which language comes out better overall in the comparison, and indeed which language would seem to be better to an uninformed reader from the points made in the article, depends on which of the advantages/disadvantages the reader considers more important, which in turn depends on 1. what programming task they are trying to accomplish and 2. what programming style they are used to (and probably several other factors).
The main reason I think the new organization is better (and in retrospect don't think the old organization was very good) is that there are plenty of points that are relevant to the article but can't be cleanly grouped into one of the original two (advantages of each) or the expanded four (advantages/disadvantages of each) categories, namely:
And so on. What concerns me most about the article currently, and about much of the debate on the talk page, is that in the quest for "neutral point of view", it seems a lot of editors are unwilling to admit that there could be any difference that is an advantage in Java, or (although this point seems to be far less commonly disputed) an advantage in C++. Even as a C++ programmer, I have to say that some of the disputes on specific differences that were originally listed as "Advantages of Java", and the resulting discussions on some of these that found their way into the article at various times (although these have been trimmed down nicely in more recent versions), seem pretty nitpicky and don't contribute much. Again, I don't see it as much, but I would make the same point for any in-depth discussions of differences that were originally listed as "Advantages of C++". It is also concerning to me how much content has been simply cut from the article, either because someone didn't agree with it or because consensus on the topic couldn't be reached on the talk page.
I don't think it is helpful either to the readability of the article, or to getting a neutral point of view, to shy away from an advantage/disadvantage viewpoint on every single difference. I think it would be much better to take a holistic approach to neutrality, and try to point out what individual differences are considered an advantage or disadvantage by a comfortable majority of programmers, even if not an overwhelming consensus. If there is not even a comfortable majority opinion about a particular difference, then of course, I agree with not trying to push either viewpoint.
Why do I care?
Of course, let me know if you disagree. CyborgTosser ( Only half the battle) 11:54, 25 January 2007 (UTC)
One bullet in the miscellaneous section reads:
"C++ compilation features an additional textual preprocessing phase, while Java does not. Thus some users add a preprocessing phase to their build process for better support of conditional compilation."
Now, I am only really familiar with C (not so much C++), but I'm pretty sure that the two languages use the same preprocessing techniques, and I know that all C++ files must be preprocessed. Any statement in C/C++ that begins with a pound sign/hash mark (#) is a preprocessor directive. Since almost every C/C++ program at the very least includes some other file using the #include
directive, it stands to reason that the preprocessor must be run on every C/C++ source file--if only to process the includes--before it is passed to the next stage.
The statement "some users add a preprocessing phase to their build process" doesn't make any sense, because there is no way to "add a preprocessing phase" (it's always there).— Kbolino 07:15, 27 February 2007 (UTC)
Please refer some System Programming book to get a clear understanding of what is a pre processor. It has nothing to do with the house keeping tasks a build tool can do( I mean Ant). Don't comapre them. They are totally different. Don't assume/imagine better to read. :-) Jayaram Ganapathy
Dear Friend, preprocessing which I discussed above is away from the build concept you are thinking. In C++ you use utilities like make, nmake , clearmake etc.. In JAVA you have Ant, maven etc. A preprocessor is something which creates source codes for compilation. Preprocessor is not used for house keeping tasks of build where I think you imagine something like creating directory structure etc..( Jayaram Ganapathy)
Currently, the performance section has the statement "However critics claims that benchmarks are the only place that Java can exceed or match C++'s performance, and in real-world applications Java is consistently slow. [5]". Unfortunately, the citation is to someone's personal web page, which is not only not peer-reviewed, but has questionable quality. I think that a rather dramatic statement like "in real-world applications Java is consistently slow" needs a reliable source, so I'm going to delete the sentence. SlitherM 18:35, 21 March 2007 (UTC)
Hello Friends, I am the person who added the link to the page. I am very new to wiki editing. So there is a very high possibility of making mistakes in wiki standard. I apologise for the same. I use both the languages JAVA and C++. What I would like you guys to think over is on the roots of computer science theories. For JAVA you have one more level of interface between the OS and the executable program. So the load is always more. On a benchmark exercise a person can produce results to favour one party. So please don't get away with that. What ever performance a JAVA program delivers always a C++ program will deliver the same or better. The logic and design of the programs plays a mojor role in the performance. The logic used to write a JAVA program if you translate and say the C++ version is not fast it is wrong. You have to rework the same logic for appropriately using the features of C++, the specific compiler you use, the OS on which you deploy and the processor. PLEASE DON'T COMPARE THE ENTIRE JAVA PLATFORM WITH C++ LANGUAGE, COMPARE JAVA PLATFORM WITH A C++ PLATFORM( C++, Compiler, OS and the processor). I am eagerly waiting for responses. :-) Jayaram Ganapathy
Hello Friend you said "If an application is required to go through the operating system for certain performance-intensive parts of the program, it is unlikely that Java could come out ahead". You are going to the hotspot optimization concept. If something is hotspot for JAVA same is hot spot for C++ too. So even in special case of hotspot codes where you see a performance benifit possibility, in the best case a JAVA can equal C++ which is determined by the CPUs capability. So your argument is irrelevent. Before making an assumption, just think if anything giving JAVA an edge is that not possible in C++? You will get answer to most of your questions. You said " If an application is required to go through the operating system for certain performance-intensive parts of the program, it is unlikely that Java could come out ahead. " An OS's scheduling algorthm determines the performance. Can you get 100% CPU assigned to a process in all UNIX based OSes? There is always a limit put by the OS how much attention a process can get at MAX. even if CPU is available many OSes won't give. JAVA in a multiprocess model I can't see anything. So a JAVA app getting 100% in windows box giving you a throughput may perform pathetically on Slightly older solaris versions :-). I have tasted this. What ever optimisation OS undergo to support JAVA, still it will not be able to compete with C++ 1) JAVA is a language designed for easy programming. Its constructs are to prevent mistakes by programmers where as C++ provides everthing to a programmer if he is good. 2) It is interpreted 3) No control over Garbage collection 4) Operations on unsigned numbers give edge in cryptography mainly which JAVA language doesn't support. 5) Type casting from one object to another object if you knwo both objects have same kind of memory alighment and so memcopy will do in C++, but unfortumately I have to call getters and setters in JAVA. Above is a smal list of issues I tasted when I ported a big C++ apps architecture to JAVA version. I do coding in JAVA but many times I felt like coding with a handicapped language. The truth is JAVA is surviving because industry lacks god programmers and people who want to really learn things.( Jayaram Ganapathy)
Although a discussion page is probably not the place for deep technical discussions, I think statements above like "I would posit that the idea that Java byte code can possibly "exceed" the performance of native machine code is impossible" and "For JAVA you have one more level of interface between the OS and the executable program. So the load is always more." should be addressed, because they seem to keep re-occuring. These seem to make common, but incorrect assumptions about how Java and C++ are executed, and what influences performance. Briefly,
So, it is not hard to imagine that Java's performance can be as good or better than C++'s. Arguments that Java HAS to have bad performance usually Incorrectly assume that Java is interpreted, or that malloc/free is free while garbage collection is slow. SlitherM 20:59, 30 April 2007 (UTC)
Well everyone thinks JIT will improve performance and stress on the same point. Just imagine the facilities available on C++. A C++ program has a preprocessing stage. Here if because of size of a function if you are not able to inline a code you can write functios in just macros. Here we are discussing about performance only. Please don't bring in maintainance and other jargons because here we compare performance. What is there in JAVA? Macros in C/C++ save memory. A techy can understand how a #define PI 3.14 and const float PI = 3.14 will save memory. Performance also means space complexity :-). Now JIT. If you want performnace all good C++ developers will use target instruction compilation switch while compiling. So forget about JIT advantage. About GC please bring to your mind that the programmer doesn't have any control over, when it will be freed. In C++ I have full control of memory. I can say when it is allocated and when it is deallocated. If I find I need more performance because malloc/new is killing me, I can create memory pools and won't hesitate to tune my app. Also note that a minimum JVM load into memory is required for a JAVA application. That is not coming for free. At the end of the day I have complete control on my application's space complexity and time complexity.( Jayaram Ganapathy)
"In contrast, C++ allows passing objects by value to functions, which can cause significant overhead in the case that much memory must be copied or inefficient copy constructors must be called.": Negative. You can - and generally, you used to - use references and pointers in implementation of algorithms. If you copy something instead of passing reference then _it is not the same algorithm_. It is general practice to pass references and constant references to functions and methods always when it is possible. Again: "... C++ allows passing objects by value ..." does not mean "... C++ allows passing object only by value ...". I cannot see the reason of this whole paragraph. And - also - it is not important how general these practices are. The possibility is there.
Many java tutorials say everything in Java is passed by value. This is obviously true for native types. However, I view objects as being passed by reference: even though the bytes of the pointer are copied, the data itself is referenced and not copied. In C, passing a pointer to another function would be considered pass-by-value.
If you think I'm wrong, please explain on my talk page. Pcu123456789 01:57, 24 May 2007 (UTC)
I think it would be more accurate to say that primitives are passed by value and object references are passed by value. 128.113.107.41 17:38, 26 May 2007 (UTC)
The Java Language Specification states explictly that Java always uses call-by-value. Period. SlitherM 04:57, 27 May 2007 (UTC)
The problem is that "pass by value" is frequently interpreted (right or wrong) as "copy the whole object graph"
http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_value which leads even this article to misleading statements like:
"Another discussion not often raised by Java programmers[weasel words] is that Java is a pass-by-value language [1], which requires much more memory copy operations[citation needed] than pointers or mutable references". —Preceding
unsigned comment added by
Davebrink (
talk •
contribs)
01:29, 5 March 2009 (UTC)
A reference in Java is a reference in Java. It is not any C++ concept and not interchangeable with any C++ concept. One similarity between references in C++ and references in Java is that we don't know (and shouldn't guess) how they are implemented, as there's nothing you can do about it, even if you find out (with a memory debugger or something). The way a reference is implemented in one implementation may or may not be the same in a different implementation. That is why talking about 'passing a reference by value' is meaningless in both languages - we don't know what the 'value' of a reference actually is in memory, and we shouldn't care; it is a meaningless concept to a user of the language. (It may have some meaning to a compiler or runtime designer, but that's not the intended audience unless we are writing about a particular compiler or JRE.) It is also equally meaningless to say 'a Java reference is a C++ pointer' or 'a Java reference is a C++ reference'. It is a separate concept - maybe somewhere between the two - but not comparable in any way that refers to 'stack', 'heap', 'address', 'memory location', 'first byte' or any other low-level or hardware concept. The languages are different abstractions of actual computer hardware and machine-code instructions; peeking behind, or guessing what's behind, the abstract scenery does not help you or the encyclopedia reader understand the language abstractions any better. -- Nigelj ( talk) 15:00, 9 December 2010 (UTC)
a=3;
foo(a);
void foo(int b) {
b=4
}
a = new Integer(3);
bar(a);
void bar(Object b) {
b = new Integer(4)
}
Now a new activation frame is created, containing the target reference (if any) and the argument values (if any), as well as enough space for the local variables and stack for the method to be invoked and any other bookkeeping information that may be required by the implementation (stack pointer, program counter, reference to previous activation frame, and the like). If there is not sufficient memory available to create such an activation frame, an StackOverflowError is thrown.
The newly created activation frame becomes the current activation frame. The effect of this is to assign the argument values to corresponding freshly created parameter variables of the method, and to make the target reference available as this, if there is a target reference. Before each argument value is assigned to its corresponding parameter variable, it is subjected to method invocation conversion (§5.3), which includes any required value set conversion (§5.1.13).
Trying to avoid favoring one these languages over the others is to miss the point, or bury the lead. The one-sentence summary of this article should be that Java is an improvement upon C++; that it is more or less an improved version of C++. That's only to be expected since Java's design had the advantage of the lessons learned from years of using C++ and other OO languages, and furthermore, C++ was handicapped by being designed as an afterthought to a non-OO, low-level language. The programming language community was able to learn a long list of lessons from C++ and and subsequent languages before the design of Java. In short, Java stands on C++'s shoulders.
Therefore, I suggest that the way to organize this page is NOT as a "C++ does this, Java does that" table that fails to show the progression from one to the other. Rather, it should be "C++ did this; Java changed it to that, and here's why... ."
Even if folks don't want the article to say that Java is an advance over C++, it is still important for the article to give the rationale behind the design choices. (And that doesn't mean giving, for each feature F, some scenarios S1..Sn where F is useful -- we can all agree that the existence of such scenarios does not constitute, by itself, sufficient reason to include feature F in a particular language, right?)
MarkAb 00:50, 11 June 2007 (UTC)
It is indeed well known that when Sun started working on Java they borrowed a lot from C++, as you said, and tried to remedy to various of its issues which were detrimental for productivity or security in specific application domains. I can certainly agree with you on that. However, Java is a higher-level language and should be seen as such; it has advantages for application programming and productivity. This can be seen as an advancement for a particular type of applications. However it would be wrong to state that C++ is not better suited for other types of applications, i.e. those more closely tied with systems programming, or those more resource constrained. Java was never intended to generally deprecate C++ and such a belief would be a false impression. Similarily, C, a predecessor of C++ still remains widely used for certain domains such as low-level kernel programming and is not about to die. 66.11.179.30 00:52, 18 June 2007 (UTC)
It is a myth that C++ fits as a low level language than High level language or JAVA is still a higher level language than C++. JAVA is a language which sticks only to Object Oriented Model. C++ is a general purpose language which is suitable for a superset of programming models. If you compare C++ and JAVA language features for OOP programming you can find a 1 to 1 mapping for the features. Actually in C++ better OOP is possible. The key difference is JAVA don't allow non-OOP programming where as C++ allows. In that way JAVA defences the programmer but the cost is paid by real good programmers is the flexibility.
As a language C++ needs lesser number of code to do a logic than JAVA. The productivity of JAVA comes from the IDE and the JSDK API. But the same library is ported to C++ the number of lines required will be less. Please note the multiple inheritance where code can be shared. There the common argument is diamond of death. But a good designer will store the data smartly inside those classes which inherit from the common ancestor. So as language C++ is a superset of JAVA for me. As of today many open source libraries are available for C++ for multithreading, cryptography etc which are provided in JSDK. The only point is they are not from a single vendor. May be a vendor like SUN can provide CPPSDK. C++ language is still evolving and the version C++ 0X is awaited. If you compare JAVA EJB's with C++ equivalents, you have Tuxedo ATMI and CORBA from BEA systems. You have to pay for that, which is rock solid. Here the inout parameters are allowed. But in EJB if you want to return multiple objects then you have to pack them inside a vector. See it is still not matuared and the additional overload. If microsoft extends support to their COM/COM++/DCOM to Unix platforms that will literally be a revelution the industry. As you can see the clock speeds of CPU are not getting increased. Now multi core systems are available but the scalability is not linear. The huge business systems which are built and runs on multiple geogrphic regions will impose strict time lines. Also the volume of business increase is faster than the speed with which hardware speed increase Jayaram Ganapathy
One thing that seems to be missing from this article is anything objectively measuring the relative market share and/or developer use of these two languages. Does anybody know of any studies that could be cited that indicate whether Java is really replacing C++? 69.81.190.216 22:16, 18 June 2007 (UTC)
This turned up in the article today. "Starting with Java version 1.5 default values for functions is allowed." I have never heard this is possible, nor can I find anything that indicates that it can. So I will delete it in a few days unless a reference turns up. Esben ( talk) 15:00, 19 December 2007 (UTC)
One of C++'s greatest features is generic programming, and is underdocumented here. The article makes it look as if Java is just slightly less powerful in this regard, but actually it is VASTLY underpowered. Concepts - the bread and butter of generic programming - can only be approximated with bound generics, which put some serious constraints on the genericity (all generics parameters have to inherit from the bound type). Otherwise, things like:
class test < T > { void foo(T t) { t.do_something(); } }
just won't work in a type-safe manner. Generic programming is also the area where operator overloading really starts to make sense. There are many examples available from Boost that could highlight this. -- 80.121.69.21 ( talk) 10:46, 12 May 2008 (UTC)
Is it just me, or has this site been hacked?
http://www.cellperformance.com/
It redirects to a fraudulent (viral) site:
http://anti-virus-secure-scanner.com/
Also, it seems the site's lease is going to expire soon anyways:
http://whois.domaintools.com/cellperformance.com
This will be posted in each of the following discussions at: http://en.wikipedia.org/wiki/Comparison_of_Java_and_C++ http://en.wikipedia.org/wiki/Aliasing_(computing) http://en.wikipedia.org/wiki/Restrict
76.64.33.246 ( talk) 06:20, 2 January 2009 (UTC)
I think this article's organization is unwieldy. • Some differences' placements are confusing. Why are unsigned arithmetic, operator overloading, and bounds checking considered "design goals"? Also, the difference between semantics and syntax here is unclear. Shouldn't pointers be in syntax? And shouldn't generics, templates, multiple inheritance, and multithreading support only be in language features? Differences like built-in support might be hard to place properly since they're language features in Java but library features in C++. • Why does the article switch between bullet points and a table format? Was this intentional? If not, I'd be happy to move the bullet points into a table format. If someone could explain this organization to me, then that would be great, and perhaps we could explain it in the intro. Otherwise, does anyone object to me trying to reorganize it? I can place my suggestions for difference categorization here first. dmyersturnbull ⇒ talk 21:42, 22 May 2009 (UTC)
I think there are a few points that are either glossed over or not discussed thoroughly enough in this article. Here's a list of what I think could be covered better:
I'm not trying to advocate Java over C++. I like both languages, and each has its strengths and weaknesses, but Java's main strengths seem to be mentioned only in passing in this article. -- Schapel ( talk) 13:56, 13 May 2011 (UTC)
Reading this article gave me quite a bit of pleasure, imagining how passionate some people can be about programming languages. The article itself is like a magnifying glass left on the top of a table filled with the history of programming languages - without the big picture it is hard to understand the details. There is no point in making a comparison between C++ and Java because the languages are not in competition, only people can do this silliness. A more neutral way to present the whole topic is by language feature, say, how do I declare objects, initialize them, pass them to methods, manage their allocation details and performance characteristics, etc. And not talk just about C++ and Java. Talk about SNOBOL, talk about Ada, talk about PROLOG. Stop living in the 21st century. Talk about the PDP/11, about Multics, about VAX/VMS, about the z80. Get serious. And take that object out of your pocket. 72.195.132.8 ( talk) 01:12, 1 July 2012 (UTC)jcb
I have added more info and deleted unneeded statements. There is huge bias on java. — Preceding unsigned comment added by 74.95.9.18 ( talk) 01:58, 19 August 2012 (UTC)
It says "* All objects are allocated on the heap." Only to then backtrack a few sentences later to explain how this is actually not true. The whole section is actually quite sad, and does not reflect the massive care that must have gone into it, judging from the size of the discussion page. 2620:0:1046:0:BE30:5BFF:FEE2:AFCF ( talk) 19:35, 4 October 2012 (UTC)
It is said that "HotSpot can remove bounds checking". But as far as I understand it's only an optimization technique which sometimes remove bound checking but not suppress it totally. Xavier Combelle ( talk) 17:33, 22 July 2013 (UTC)
If we're going to say that "Various aspects of the language are covered by patents and copyrights held by Oracle.", then we need a cite to back it up. Oracle_v._Google says the opposite, that provided they avoid copying code, Google can implement Java (and all its APIs) even over Oracle's objections. http://www.javaworld.com/jw-10-1997/jw-10-lawsuit.html says "the complaint charges Microsoft with trademark infringement, false advertising, breach of contract, unfair competition, interference with prospective economic advantage, and inducing breach of contract." That long list does not include copyrights or patents. If we're wildly speculating, http://communities.mentor.com/community/cs/archives/cxx-abi-dev/msg01295.html is a list of possible patents over C++ implementations (not really from a reliable source) and if GCC's C++ implementation violates any of them, so almost certainly does GCC's Java implementation, as they share an ABI... and IBM and Microsoft are the corporate names on those patents, not Oracle.-- Prosfilaes ( talk) 08:24, 27 October 2013 (UTC)
Guys/Gals,
Java does not support multiple inheritance. <---- note that there's a period at the end of that sentence
I call your attention to: http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)
Specifically, the fact that that article begins by stating that *implementation* is what is being inherited, NOT TO BE CONFUSED with subtyping:
http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Inheritance_vs_subtyping
Anyone who understands multiple inheritance and its problem(s) would know quite well that Java does not support multiple inheritance, and the creators of Java were very vocal and open about their reasons for excluding multiple inheritance from the Java language spec.
Aquishix ( talk) 12:19, 10 February 2014 (UTC)
I believe there is an error in the generics vs. templates comparison section.
It says (as of 11/18/2015):
C++ Templates | Java Generics |
---|---|
Templates can be specialized—a separate implementation could be provided for a particular template parameter. | Generics cannot be specialized. |
The below program shows an example of specializing a generic method for a specific template parameter. The "myCount" method is specialized for subclasses (inclusive) of Character. Is this not "providing a separate implementation for a particular template parameter"? It seems to precisely match the definition of "Explicit template specialization" given here: Template (programming)#Explicit template specialization
import java.util.*;
public class Test {
static <T> int myCount (Iterator<T> iterator, T val)
{
int ret = 0;
while (iterator.hasNext()) {
T entry = iterator.next();
if (entry.equals(val)) ++ret;
}
return ret;
}
static <T extends Character> int myCount (Iterator<T> iterator, T val)
{
System.out.println("weirdcount");
int ret = 0;
while (iterator.hasNext()) {
T entry = iterator.next();
if (entry.equals(val)) ++ret;
}
return ret*3;
}
public static void main (String[] args) {
List<Integer> nums = new ArrayList<>(Arrays.asList(1,2,3,3,3,4,5,2,1));
int count = myCount(nums.iterator(), 3);
System.out.println(count);
List<Character> characters =
new ArrayList<>(Arrays.asList('a','b','c','d','e','a','b'));
int count2 = myCount(characters.iterator(), 'a');
System.out.println(count2);
}
}
Thanks, Vancan1ty ( talk) 04:35, 19 November 2015 (UTC)
I think the article should also state that C++ nested classes differ from Java inner classes. C++ nested classes are kinda like a static class in Java and can not access fields in the outer class unless they are static (C++11)
Hello fellow Wikipedians,
I have just modified one external link on Comparison of Java and C++. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}}
(last update: 5 June 2024).
Cheers.— InternetArchiveBot ( Report bug) 16:29, 11 August 2017 (UTC)