Talk:Comparison of Java and C++

message: 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)
thread_title: Untitled

message: 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)
thread_title:  resource 

message: 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)
thread_title:  contributions by 68.68.100.185 

message: 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)
replies: text: OK, I renamed the page as above. – Doug Bell talk•contrib 05:00, 6 March 2006 (UTC)

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

text: See also, later on, "In Java, parameters are passed using pass-by-reference for non-final objects and pass-by-value for final objects and primitives.". Again, AIUI, what is actually happening is that an object reference is being passed-by-value. 80.168.196.219 20:24, 27 April 2007 (UTC)

text: The last bit about "pass-by-reference for non-final objects" was made after I wrote the above question, and is, of course, completely wrong.  I've fixed it once more. As for the original question about the line in the table, since nobody seems to know what that line is supposed to mean, other than confusion about parameter passing, I replaced the line with a statement about parameter passing.  SlitherM 14:44, 30 April 2007 (UTC)
thread_title:  references for the design goals of C++ (and Java) 

message: 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)
thread_title: Cleanup tags

message: 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.  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)
replies: text: I do not know whether multiplying integers uses a separate instruction from multiplying floating-point values (I assume by "reals" you meant "floating-point values" as integers are real numbers) in the JVM (it does on most real processors).  However, I do know that they are semantically the same (whereas addition and concatenation are not), and as such it does not qualify as overloading from a language perspective.  This applies to addition, subtraction, division, and modulus, as well as all derived operations (+=, -=, etc.)—Kbolino 01:22, 4 April 2007 (UTC)
replies: text: Yeah, this is wrong. I've fixed it. This is the second time I've had to do so -- there seems to be general confusion about Java's parameter passing.  SlitherM 14:52, 30 April 2007 (UTC)
thread_title:  Some inaccuracies 

message: 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)
thread_title:  Arrays in C++ 

message: 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.
Jayaram Ganapathy
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)
replies: text: Jayaram Ganapathy doesn't say specifically what he/she thinks is biased about the references section, but it appears to be related to his/her comments in the #Performance section.  Apparently, Jayaram believes that there are theoretical reasons why Java performance has to be slower than C++'s, and that therefore the references which say that this is not the case must be biased.  There is a discussion about this in that section.  If I've misunderstood Jayaram's reasons for thinking that the references are biased, then perhaps he/she could clarify.  Otherwise, discussion should probably continue there.  SlitherM 15:10, 30 April 2007 (UTC)
thread_title:  Propaganda 

message: 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)
thread_title: What is the point of this article?

message: 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)
thread_title: Intro

message: 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)
replies: text: Yes, Java is a safe language and C++ is an unsafe language, in the terminology of type safety. Java does not allow arrays to be accessed out of bounds or dereferencing arbitrary memory locations as C++ does. I think the article already discusses this point in plenty of detail. Do you think something should be changed or added? Should we add the tradeoffs, such as Java does not allow buffer overflow errors which are common in C++ programs, although C++ permits interfacing with low-level hardware by allowing arbitrary memory accesses which Java does not allow? -- Schapel (talk) 14:30, 15 January 2011 (UTC)

text: Note, that this argument was only true in 90s when the internet protocols didn't ensure failure-free communication. Since TCP-IP became widespread, the applications don't need to ensure the data integrity themselves as TCP-IP is failure-free protocol, so the argument is void. You may find interesting that supercomputers do not have any problems using C/C++ frameworks for communication between nodes. The result of any 'glitches' in the communication could be even more disastrous than you might think. A good illustration of this is that supercomputers usually use error-free components even though they cost several times more than consumer equipment. 1exec1 (talk) 12:27, 16 January 2011 (UTC)
replies: text: You're misunderstanding what My Flatley was trying to say. To be honest, he didn't explain very well. The problems of C++ have nothing to do with communication. That's a red herring. The issue is that a Java program cannot have a security issue such as a buffer overflow problem, which C++ programs can have. That's why it can be unsafe to download and run a C++ program. -- Schapel (talk) 13:09, 16 January 2011 (UTC)
thread_title: Reasons for preferring one language over the other

message: 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)
replies: text: Yes, that would be interesting. I don't know if there are any statistics available and what they cover. One possibility to create such statistics is to mine data bases, basically searching for occurrences of java or C++ code. My first idea was google code search, however the problem with google is that every time the number varies. A more realistic possibility would be to search academic articles for java and c++ the idea being to count references from research to one of the two languages. This search could even allow charting references by years. Ben  T/C  12:49, 16 April 2009 (UTC)
thread_title:  Usage metrics 

message: 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)
thread_title:  Default parameters in Java 

message: 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)
replies: text: Except that Concepts do not exist in the current version of C++. --Spoon! (talk) 11:47, 12 May 2008 (UTC)
replies: text: Actually, the above would work today. You might be confusing the above with the Concept proposal for C++0x, which is meant for better compiler error messages. But concepts will not change what is possible to do safely. I would encourage a section where generics are compared to templates, but well down as it is an advanced subject. Esben (talk) 09:40, 13 May 2008 (UTC)
replies: text: It will "work" today if you somehow figure out how to use it correctly. There is nothing in the signature of the class or function that tells you what kind of types T can be. When you use it with a type that doesn't have a "do_something" method, then it will blindly try to instantiate the template, and then fail halfway through, giving some convoluted message about a line inside the foo() method. That is about as "safe" as C macros are "safe". Your code example above shows what is fundamentally "unsafe" about C++ templates. A "type-safe" language should not allow the above code, because its type declaration does not by itself guarantee that it will work. In Java, that code would not be allowed, and the compiler would force you to bound the type parameter in a way that makes sure it has such a method, which guarantees that it will work, completely independently of any other code. Any other code (which can be compiled separately) will have to follow the type restrictions (if they do not follow it it gives an error on their end). That is the whole point of safety - the restrictions you place on it must convince the compiler that it will work. With Concepts in C++0x, you would bound the type T by some concept, which also achieves safety (which is important in its own right, not just for better compiler messages); but this is not currently in C++. --Spoon! (talk) 10:43, 13 May 2008 (UTC)
replies: text: First of, what you get from Java with those bound are available in C++, as a (boost) library. Secondly, the safe typing is what is sometimes referred to as duck typing, which is considered by many to be just as safe as the hieraki. But I don't care to bicker with you, not here :) Esben (talk) 21:08, 19 May 2008 (UTC)
thread_title:  Generic programming: important parts missing 

message: 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)
thread_title:  Reference to Compromised URL 

message: 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)
thread_title:  Organization? 

message: 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:
* Java is a typesafe language. Many errors that can happen in C++ are either disallowed by Java's bytecode verifier or trapped at runtime. Buffer overflow problems are just one example. On the other hand, this can allow C++ to have better performance (reference).
* Java does not have the fragile binary interface problem problem that C++ does. This is glossed over by the general term "binary compatibility", but the article doesn't seem to explain the repercussions of binary compatibility or the lack of it.
* Java does not have separate header files as C++ does. This could be consider a strength or weakness, but some advantages are that makefile dependencies do not need to be updated in Java, and Javadoc comments allow documentation for classes and interfaces separate from the source code.
* C++ must be recompiled for each different platform.
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)
thread_title:  Some missing points 

message: 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)
replies: text: The recent statements I have seen demonstrate a much higher bias for one particular side than what was in the article before. The edits are also quite poor. Perhaps you should start slowly in Wikipedia, in a topic you are more familiar with. -- Schapel (talk) 02:05, 19 August 2012 (UTC)

text: You should also cite sources — content without citations may be removed if challenged. As you're doing that, you might realize why I suggested for you to start slowly and in an area you're more familiar with. -- Schapel (talk) 04:12, 19 August 2012 (UTC)
thread_title:  Bias and citing sources 

message: 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)
thread_title:  Stupid stuff in the performance section 

message: 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)
thread_title:  remove bounds checking 

message: 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)
thread_title:  Multiple Inheritance in Java 

message: 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)
thread_title:  Java Generics Inaccuracy 

message: 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:
*Added archive https://web.archive.org/web/20020402093228/http://www.ora.com/catalog/javanut/excerpt/index.html to http://www.ora.com/catalog/javanut/excerpt/index.html
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
Cheers.—InternetArchiveBot (Report bug) 16:29, 11 August 2017 (UTC)
thread_title:  External links modified