Talk:Comparison of Java and C++: Difference between revisions

Revision as of 16:54, 17 March 2006

Latest revision as of 01:20, 8 February 2025

(195 intermediate revisions by 79 users not shown)

Line 1:

{{Talk header}}

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

{{Old AfD multi |date=17 December 2021 |result='''keep''' |page=Comparison of Java and C++}}

{{WikiProject banner shell|class=List|1=

{{WikiProject Computing |importance=low}}

{{WikiProject Java |importance=low}}

{{WikiProject C/C++ |importance=low }}

}}

{{User:MiszaBot/config

|archiveheader = {{Talk archive}}

|algo = old(365d)

|maxarchivesize = 100K

|minthreadsleft = 5

|minthreadstoarchive = 1

|counter = 2

|archive = Talk:Comparison of Java and C++/Archive %(counter)d

}}

== Maintainingremove abounds NPOVchecking ==

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. [[User:Xavier Combelle|Xavier Combelle]] ([[User talk:Xavier Combelle|talk]]) 17:33, 22 July 2013 (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.

== Copyrights and patents ==

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.

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.--[[User:Prosfilaes|Prosfilaes]] ([[User talk:Prosfilaes|talk]]) 08:24, 27 October 2013 (UTC)

I urge future editors to not show bias.

:Your last observation is interesting, but irrelevant here. The point is, Oracle may at any time assert it's intellectual rights over various aspects of the Java language. Moreover, the verdict in the Oracle/Google lawsuit does not in any way affect their right to sue even on the very same grounds laid out in that particular lawsuit, and however unlikely, they could still win such a lawsuit. And please note that a large part of that lawsuit was simply an objection to Google duplicating the Java API of all things! Which means, of course, that the types of complaints filed in any future lawsuit are only limited by the creativity of Oracle's legal department. [[User:Sebastiangarth|Sebastian Garth]] ([[User talk:Sebastiangarth|talk]]) 13:45, 27 October 2013 (UTC)

:: The point is, Microsoft may at any time assert its intellectual rights over various aspects of the Java and C++ languages. So might IBM. So might any other huge patent holder. So might any designer of a pre-Java API who wanted to claim that Java's API is a copyright infringement of theirs. Looking at the results of the SCO trial, it's not at all improbable that somewhere BSD-licensed code snuck its way into Oracle's Java implementation sans proper copyright notice. All of this might happen, and all of it is [[WP:CRYSTAL|crystal-balling]].

:: Yes, Oracle could sue on the same grounds. There's very few limitations on what people can sue on. Speculating that they could win such a lawsuit is, again, crystal-balling, and again, Oracle is not unique in having a creative legal department.

:: Going back to the original statement, nobody has ever shown that a language can be covered by copyrights, and [[Oracle v. Google]] said they couldn't, or at least Java wasn't. Neither 6061520 or RE38104, the two patents brought up in the Oracle trial, seem to be about Java as much as ways to implement Java. If we want to make the claim under question, we should speak with specificity and with cites. (And we should avoid saying anything about Oracle's "intellectual rights" over Java. That's not a clear term. We should speak specifically of copyrights, patents or trademarks, each of which has very different extents and limitations.)--[[User:Prosfilaes|Prosfilaes]] ([[User talk:Prosfilaes|talk]]) 17:40, 27 October 2013 (UTC)

:::I do understand your point but I still must disagree here. At any rate, I'm not going to press the issue any further. Perhaps we'll revisit the discussion sometime in the future. For now, at least, we can leave the wording as it is. [[User:Sebastiangarth|Sebastian Garth]] ([[User talk:Sebastiangarth|talk]]) 19:36, 27 October 2013 (UTC)

== Multiple Inheritance in Java ==

-- [[User:Eelis.net|Eelis]] 01:53, 2005 May 23 (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)

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. [[User:CyborgTosser|CyborgTosser]] ([[User_talk:CyborgTosser|Only half the battle]]) 20:22, 25 Feb 2005 (UTC)

Specifically, the fact that that article begins by stating that *implementation* is what is being inherited, NOT TO BE CONFUSED with subtyping:

For reference, here is the original merge request as posted by [[User:Netoholic|Netoholic]]:

:''This article or section should be [[Wikipedia:Duplicate articles|merged]] with the [[Java programming language]] & the [[C Plus Plus|C++ programming language]].

http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming)#Inheritance_vs_subtyping

[[User:CyborgTosser|CyborgTosser]] ([[User_talk:CyborgTosser|Only half the battle]]) 20:27, 25 Feb 2005 (UTC)

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.

: 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. -- [[User:Netoholic|Netoholic]] [[User talk:Netoholic|@]] 22:12, 2005 Feb 25 (UTC)

[[User:Aquishix|Aquishix]] ([[User talk:Aquishix|talk]]) 12:19, 10 February 2014 (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. [[User:CyborgTosser|CyborgTosser]] ([[User_talk:CyborgTosser|Only half the battle]]) 23:28, 25 Feb 2005 (UTC)

== Java Generics Inaccuracy ==

== resource ==

I believe there is an error in the generics vs. templates comparison section.

This article equates resource with memory, but a resource might also be a lock that is acquired and lots of other things too.--[[User:MarSch|MarSch]] 15:05, 27 October 2005 (UTC)

It says (as of 11/18/2015):

== contributions by 68.68.100.185 ==

{| class="wikitable"

! '''C++ Templates''' !! '''Java Generics'''

|-

| Templates can be [[Template (programming)#Explicit template specialization|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]]

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

<syntaxhighlight lang="java">

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

import java.util.*;

public class Test {

i've updated accordingly. critique, rebut, modify at will ;) --[[User:Pfunk42|pfunk42]] 14:54, 26 December 2005 (UTC)

static <T> int myCount (Iterator<T> iterator, T val)

== Edits by 84.61.26.158 on January 10, 2006 ==

{

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)

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 [[User:84.61.26.158|84.61.26.158]] in the excepts from the article below are shown in '''''bold italics'''''.

{

System.out.println("weirdcount");

* '''''C++ features callbacks, which must be simulated in Java using trampolines.'''''

int ret = 0;

while (iterator.hasNext()) {

:I have a couple issues with this. First, [[callback (computer science)|callbacks]] are not a feature of C++, but rather a use of [[function pointer]]s (or [[function object|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 (computers)|trampoline]]. -- [[User:Doug Bell|Doug Bell]] 23:12, 10 January 2006 (UTC)

T entry = iterator.next();

if (entry.equals(val)) ++ret;

::Removing it, but a good statement regarding function pointers should be put in. --[[User:Pfunk42|pfunk42]] 19:10, 11 January 2006 (UTC)

}

return ret*3;

* C++ supports <code>[[goto]]</code> statements; Java does not, but its [[Labelled break|labelled breaks]] provide some </code>goto</code>-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 </code>goto</code> 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 </code>goto</code> makes code less readable. That makes this statement an unbalanced POV. -- [[User:Doug Bell|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. --[[User:Pfunk42|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? -- [[User:Doug Bell|Doug Bell]] 23:12, 10 January 2006 (UTC)

::I'm reverting it. 84.61.26.158 is wrong. --[[User:Pfunk42|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 ([[deadlock]]s and [[race condition]]s). 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 <code>synchronized</code> 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. -- [[User:Doug Bell|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". --[[User:Pfunk42|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. --[[User:Pfunk42|pfunk42]] 19:10, 11 January 2006 (UTC)

:Actually, <code>System.runFinalizersOnExit</code> 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 <code>System.runFinalization</code> will not guarantee execution of the finalizers. I readded the statement and expanded the comparison of destructors and finalizers.-- ''[[User:Doug Bell|Doug Bell]]'' <span style="font-size: 8pt">[[User talk:Doug Bell|talk]]/[[Special:Contributions/Doug Bell|contrib]]</span> 21:13, 11 January 2006 (UTC)

== references for the design goals of C++ (and Java) ==

The article contains this table:

<blockquote>

The different goals in the development of C++ and Java resulted in different [[principle]]s and design [[tradeoff]]s between the languages.

:{| class="wikitable"

! '''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

|}

</blockquote>

public static void main (String[] args) {

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. [[User:MarSch|MarSch]] 13:21, 5 March 2006 (UTC)

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 =

* 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. :) --[[User:Pfunk42|pfunk42]] 14:58, 5 March 2006 (UTC)

new ArrayList<>(Arrays.asList('a','b','c','d','e','a','b'));

int count2 = myCount(characters.iterator(), 'a');

System.out.println(count2);

}

}

</syntaxhighlight>

Thanks,

[[User:Vancan1ty|Vancan1ty]] ([[User talk:Vancan1ty|talk]]) 04:35, 19 November 2015 (UTC)

== nested/inner classes ==

* 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. &ndash; [[User:Doug Bell|Doug Bell]] ^{[[User talk:Doug Bell|talk]]'''&bull;'''[[Special:Contributions/Doug Bell|contrib]]} 05:00, 6 March 2006 (UTC)

** ''implies that for example execution efficiency and developer productivity are opposites''<br>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''<br>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.''<br>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.''<br>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. &ndash; [[User:Doug Bell|Doug Bell]] ^{[[User talk:Doug Bell|talk]]'''&bull;'''[[Special:Contributions/Doug Bell|contrib]]} 18:23, 5 March 2006 (UTC)

I think the article should also state that C++ nested classes differ from Java inner classes.

==Cleanup tags==

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) [[User:Peter.quiring|Peter.quiring]] ([[User talk:Peter.quiring|talk]]) 22:42, 4 April 2016 (UTC)

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++]]?

&mdash;<tt>[[User:donhalcon|donhalcon]]</tt>^{[[User talk:donhalcon|╤]]} 05:47, 6 March 2006 (UTC)