Talk:Comparison of Java and C++

From Wikipedia, the free encyclopedia

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

Contents

[edit] Maintaining a NPOV

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:

  • For sequential arithmatic, Java and C++ are on the same level. However, Java cannot support vector processing because its very processor dependant. C++ allows one to craft code designed for specific processors, opening up the use of SSE or AltiVec.
  • A search for Java DSP or Java vector arithmatic yields no hits for while doing similar searches for C++ yield libraries designed for native interfacing with the vector processors.

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:

This article or section should be merged with the Java programming language & the C++ programming language.

CyborgTosser (Only half the battle) 20:27, 25 Feb 2005 (UTC)

My main point is that there are infinite combinations of comparison articles possible (just the top 10 languages alone would lead to 45 such articles). A much better approach would be to put the "Advantages" and "Disavantage" sections within each language article itself. That way, you can reduce the redundancy where a language has dis/advantages over multiple other ones. -- Netoholic @ 22:12, 2005 Feb 25 (UTC)
There are many possible combinations for articles, but probably only about a dozen that would make interesting articles. In particular, when one language is strongly influenced by another (this article) or if the languages represent a split in design philosophy within a given paradigm (such as OCaml vs. Lisp), there is a possibility for an interesting article. An advantages/disadvantages section in each article would be a good idea, but as long as the number of comparison articles we have doesn't grow without bounds, I don't think there will be a lot of redundancy. Look, for example, at this article and the comparison of Java to C#. What gives Java an advantage/disadvantage compared to C++ is not the same as compared to C#. But I will take a "wait and see" attitude on this. If I am wrong and there is a ton of redundancy as more of these articles pop up, then I'm in support of consolidation. CyborgTosser (Only half the battle) 23:28, 25 Feb 2005 (UTC)

[edit] resource

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)

[edit] contributions by 68.68.100.185

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)

[edit] Edits by 84.61.26.158 on January 10, 2006

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.

  • C++ features callbacks, which must be simulated in Java using trampolines.
I have a couple issues with this. First, callbacks are not a feature of C++, but rather a use of function pointers (or functors). So a callback is not a feature of C++ (although function pointer is a feature that can be compared). Second, the mechanism in Java is to use an object for a callback, or more pointedly, to define the callback method using an interface and pass an object that implements the interface in place of the C++ function pointer. This mechanism does not match the definition of a trampoline. -- Doug Bell 23:12, 10 January 2006 (UTC)
Removing it, but a good statement regarding function pointers should be put in. --pfunk42 19:10, 11 January 2006 (UTC)
  • C++ supports 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.
I corrected the spelling, but left the statement. My problem with this is that while there can be a case made for limited circumstances where a goto can make code more readable (and most of these cases are obviated by the use of exceptions to handle errors and exception execution paths), there are many more cases where the use of goto makes code less readable. That makes this statement an unbalanced POV. -- Doug Bell 23:12, 10 January 2006 (UTC)
That can make code distinctly less readable. I have no idea what "that" is supposed to refer to, so this statement is gone. I see no POV problem with the way it was because with the goal of leaves the reader to draw his/her own conclusion as to whether enforcing structured control flow makes code easier to understand. --pfunk42 19:10, 11 January 2006 (UTC)
  • The encoding of string and character literals in C++ is as the programmer sees fit.
This used to say "platform dependant". I wasn't aware that it was a feature of C++ to allow the programmer to determine how the compiler encodes string and character literals. Perhaps this is a feature of some specific C++ compiler? -- Doug Bell 23:12, 10 January 2006 (UTC)
I'm reverting it. 84.61.26.158 is wrong. --pfunk42 19:10, 11 January 2006 (UTC)
  • In Java, all code is implicitly multithreaded, though most programmers are unaware of that fact. Deadlocks can thus easily happen.
I have a few issues with this statement.
  • Deadlocks do not easily happen in Java because of the inherent multi-threaded nature of Java programs. This is because unless a Java program is operating in a multi-threaded context, such as an Applet or applications with a GUI, all of the main application code and objects run in, and are accessed from, a single thread. There is no opportunity for contention or deadlock.
  • Both C++ and Java programs that run in a multi-threaded context can suffer from problems inherent in multi-threaded programs (deadlocks and race conditions). This includes any applications that support call backs or events, to name a couple. This means that the issue of deadlock is not a Java phenomenon, but rather a multi-threaded programming phenomenon relavent to both Java and C++.
  • The statement that most programmers are unaware of when they are programming in a multi-threaded context is unsubstantiated speculation.
I'm assuming that the underlying issue here is the Java 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)
I'm removing it. If you don't declare multiple threads in your code, deadlock is impossible. Wait, the Swing thread pops up implicitly, but that doesn't fall under "happening easily in all code". --pfunk42 19:10, 11 January 2006 (UTC)
  • which might never happen. Guaranteed execution of finalizers before exit can be requested through the API. ==> removing qualifier. --pfunk42 19:10, 11 January 2006 (UTC)
Actually, 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)

[edit] references for the design goals of C++ (and Java)

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)

  • if your commentary isn't a totally biased Java flame, i don't know what is. POV! POV! POV!!! (i can say it too). . . . more seriously, i think you're taking the table to mean a lot more than intended. the table outlines rough design goals. it's not meant to be conclusionary about the efficacy or merits of those goals, or how elegantly the languages fulfill those goals. . . . but also, some of what you say is just wrong. :) --pfunk42 14:58, 5 March 2006 (UTC)
  • While, as pfunk42 points out, there are many points where MarSch is just wrong, I think s/he makes a couple good points. First, a better name for the article would be Comparison of Java and C++. Second, there should be references for the languages respective design goals. However, these points are completely wrong:
OK, I renamed the page as above. – Doug Bell talk•contrib 05:00, 6 March 2006 (UTC)
    • implies that for example execution efficiency and developer productivity are opposites
      Nothing of the sort is implied. What is stated is that each language had principles that established priorities that guided the design of the language.
    • supports developer productivity with generic programming, unlike Java
      Uh, right there in the article it talks about comparing generics and templates and even references a sibling article Comparison of generics and templates that compares the two features in depth.
    • All other entries also suffer from POV or are simply false.
      This statement clearly suffers from both POV and simply being false.
    • The fact Java doesn't support operator-overloading or templates, doesn't make it easier to use.
      A point that can be argued to death without ever reaching a decisive conclusion because "easier" is subjective and not uniquely quantifiable...however, the points in the table are, as pfunk42 points out, discussing goals, not outcome.
The rest of the points raised by MarSch are POV. This article has been edited by both Java, C++, and Java + C++ users and while it can be better, it is not a one-sided myopic view of the subject as MarSch seems to suggest. – Doug Bell talk•contrib 18:23, 5 March 2006 (UTC)

[edit] Cleanup tags

I've added three cleanup tags to this article.

  • Tone: This article consists mainly of bulleted lists of features, rather than a more encyclopedic discussion of fundamental issues.
  • Not verified: The article does not cite sources sufficiently, especially in the "Design aims" section; it makes a number of unverified (and implementation-dependent) claims about speed and size, as well as a few about ease of programming and/or maintenance.
  • Importance: What information does this article provide that is not already covered by Java programming language and C++?

—donhalcon╤ 05:47, 6 March 2006 (UTC)

[edit] Syntax power!

"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)

"power" in the sense of doing more with less. --pfunk42 16:56, 3 June 2006 (UTC)
in which case, "expressive" or "compact" are more specific adjectives that might be worth considering instead. JulesH 10:43, 17 July 2006 (UTC)
From my experiance, "power," is the adjective most comonly used to describe a syntax which allows for a great deal of versitility with a minimal number of keystrokes. This matches C++ very well. And "powerful" is accurate in annother way - C++ can do more than Java, because Java has chosen to sacrifice power for safety. Just as C++ offers you more power to do what you want, it also offers you more power to hang yourself with a sphagetii goto mess with a dangling pointer while your boss gives you questioning looks during the demonstration.CmdrRickHunter 06:10, 2 August 2006 (UTC)

[edit] Java-centric

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. —The preceding unsigned comment was added by Kentfx (talk • contribs).

[edit] Some inaccuracies

Some things I believe are inaccurate, but which I'm not updating because I don't have sources for most of this.

Still it's possible to have memory leaks in java, via cross-referencing, on most JVM implementations. Two unused object (not referenced anymore by the main application) could reference themselves so they are still marked as used and not garbage-collected.

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.

In Java, assembly code can only be accessed as libraries, through the Java Native Interface. However, there is significant overhead for each call.

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."

Both Java and C++ distinguish between native types (these are also known as "fundamental" or "built-in" types) and user-defined types (these are also known as "compound" types). However, in C++ this distinction is far less extensive.

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).

Due to the lack of constraints in the use of some C++ language features (e.g. unchecked array access, raw pointers), programming errors can lead to low-level buffer overflows, page faults, and segmentation faults.

Java can cause page faults too, you know. Changing "page faults and segmentation faults" to "memory access violations" might make sense.

In C++, if you have an array, or a pointer to an array, or a reference to an array, you can determine the array's size using the "sizeof" operator; however, if you only have a pointer to the first element of an array, its size cannot be determined.

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))

[edit] Arrays in C++

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:

  • An array of ints is similar to a pointer to an int.
  • An array of an array of ints is similar to a pointer to an array of ints, which is similar to a pointer to a pointer to an int.

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)

[edit] Propaganda

As of now, this "encyclopaedia" material reads like a JAVA evangelist pamphlet, sorry. Totally unaceptable. —The preceding unsigned comment was added by 85.138.1.15 (talk • contribs).

[edit] What is the point of this article?

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)

[edit] Proposal

OK since Doug objected to the article being deleted which is fine I make the following proposal:

  • The article is heavily tagged and with good reason. Someone needs to rewrite it and make it more balanced and relevant. Also, please keep in mind that even though what you write may be true it must not be original research. It needs to be either sourced or common knowledge as defined per policy. If you believe that something is common knowledge within a fairly specialized field like programming then please explain why on the talk page. It doesn't have to be a long speech just a short explanation why you believe it is not original research.
  • Alternatively I suggest that the content be merged into the Java and C++ articles.
  • If all else fails I will nominate the article for deletion through AfD.

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)

I don't disagree with any of your statements except for the notion of merging this into the Java and C++ articles. Those articles already have enough to cover without including language vs. language comparisons, and duplicating these comparisons in each article is worse than having them here.
I would appreciate if you could expand on what you mean by "more balanced and relevant". Also in reading this article I'm trying to understand the primary complaint behind the POV tag. The article seems fairly (not perfectly) balanced—I would think the primary issue would be to cite sources and maybe restructure so as to be an article instead of an organized list.
Despite having spent some time improving this article in the past (if you think it is bad now, you really wouldn't have liked it before), I'm not sure I will be the one to put the time in to improve it further. I simply think that an article that's been edited by dozens of editors almost 300 times over more than 4½ years needs to go through WP:AFD instead of WP:PROD. —Doug Bell talk•contrib 10:14, 11 November 2006 (UTC)
I can see how it has been greatly improved. I am going to go through the edit history and see when the tags where added and see whatever issues have already been resolved without the tag being removed.
Regarding balance and relevance parts are why I was reacting initially
C++ supports goto statements; Java does not, but its labelled break and labelled continue statements provide some structured goto-like functionality. In fact, Java enforces structured control flow, with the goal of code being easier to understand.
Goto statements are very very rarely used by C++ programmers. C and C++ programmers generally try very hard to maintain structure throughout the code to make it easy to understand. C++ programmers also use classes like Java programmers to maintain structure (among other advantages).
A consequence of this is that although loop conditions (if, while and the exit condition in for) in Java and C++ both expect a boolean expression, code such as if(a = 5) will cause a compile error in Java because there is no implicit narrowing conversion from int to boolean. This is handy if the code were a typo for if(a == 5), but the need for an explicit cast can add verbosity when statements such as if (x) are translated from Java to C++.
The part about forcing the programmer not to use implicit narrowing is fine. However, the last sentence does not seem relevant in a comparison of the two languages. It is not about the pros and cons of porting from Java to C++ (which is often avoided anyway since the choice of language has been made to begin with and most (not all though) C++ code predating Java has been heavily updated since.)
This additional functionality is available for C++ by (often free) third party libraries, but third party libraries do not provide the same ubiquitous cross-platform functionality as standard libraries.
This point that Java is more portable than C++ is made throughout the article and bugs me. C++ was designed to be portable. It contains no platform-specific parts itself. The STL was also meant to be portable. Also, the libraries the article talks about are in fact highly portable in most cases and maintained under the GPL. I think the point the article is trying to make is that the portability is largely implemented in the Java Virtual Machine and not in the Java code itself. C++, being more low-level, does not enjoy this advantage. However, that is not due to C++ being flawed but rather because certain software vendors have decided to add and change "features" that make it harder to port code that depends on low level system calls. But then the article should put it that way instead.
I can see why you would not want to merge the content into the two other articles. MartinDK 11:00, 11 November 2006 (UTC)
OK the tone and not verified tags were added on March 6, well over 7 months ago. The article has been heavily edited since then so I am removing them from the article. That leaves 2 tags that need to be removed... that makes it easier. MartinDK 11:23, 11 November 2006 (UTC)

[edit] Intro

Cut from intro:

While C++ and Java share many common traits, their differences can make a simple task extremely difficult if the wrong language is chosen. For example, Java does not work well when it is forced to work directly with hardware, and C++ does not work well when reflection is required. If features from both languages are required, a programmer can use JNI to bridge between them, but that is outside of the scope of this article.

Where is any of this expanded on, after the intro? --Uncle Ed 20:31, 20 November 2006 (UTC)

[edit] Reasons for preferring one language over the other

I am totally neutral on which language is better, but I cut this:

As such, both C and C++ provide good support for both application and systems programming.

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

  • The Java compiler supplied by Sun includes bounds-checking for arrays, and you can't turn it off. This is good because blah, blah, blah. This is bad because yadda yadda yadda.
  • C++ provides direct access to memory. This is good because, etc. This is bad because, etc.

Keep it neutral in terms of ducking any conclusions, but let all voices speak! --Uncle Ed 20:43, 20 November 2006 (UTC)

Retrieved from "http://en.wikipedia.org../../../c/o/m/Talk%7EComparison_of_Java_and_C%2B%2B_e1a8.html"