Java vs C/C++

Please compose all posts in Emacs.

Moderators: phlip, Moderators General, Prelates

User avatar
Jplus
Posts: 1709
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Java vs C/C++

Postby Jplus » Wed May 05, 2010 4:42 pm UTC

Meteorswarm: yes, purely functional languages are the safest.

0xBADFEED: your points on legacy code from the pre-smart pointer era and on stack overflows convinced me. I don't agree to everything you said, though.
Since the introduction of decent smart pointers there is no reason to consider "raw" pointers the default, as the techniques are equally accessible to the developer. Using smart pointers doesn't require any more effort from the programmer than using raw ones (in fact, smart pointers require less thinking and less typing). Also, there is nothing about C++ that pushes programmers to use raw pointers rather than smart pointers, and in fact most programmers in the C++ community are now encouraging each other to use the smart ones. Which of the techniques is the default mostly depends on the culture, and the culture has been heading towards smart pointers at least since 2003. The transition isn't over yet, but soon we will consider raw pointers a "special case" which you only use for systems programming.
And yes, the mainstream smart pointer implementations assume that you don't fiddle with the underlying raw pointer. Therefore they don't check for null pointers. I think that doesn't pose much of a problem for safety, because if you're fiddling with the underlying raw pointer you're pretty much causing the problems on purpose.
Spoiler:

Code: Select all

//using a smart pointer as they're always taught to be used
{
    shared_ptr<int> our_pointer = new int;  // no way to retrieve the underlying
                                            // raw pointer
    // ... do something with it
}   // our freestore int is automatically deleted, guaranteed without problems

// using both mechanisms on purpose to defeat the purpose of smart pointers
{
    int *raw_pointer = new int;  // first save the raw pointer value so you can
                                 // access it later
    shared_ptr<int> our_pointer = raw_pointer;  // the shared_ptr doesn't know of the
                                                // cheating
    delete raw_pointer;  // mess with the raw pointer which you shouldn't have in the
                         // first place
    raw_pointer = 0;     // mess more with the raw pointer
    shared_ptr<int> their_pointer = raw_pointer;  // again deception of a smart pointer
    int x = *their_pointer;  // ouch! null pointer
}   // armageddon (deletion of dangling our_pointer)

But again, I must admit that you're right about the old legacy code issue and that does make such uses of C++ inherently less safe than Java. Same for stack overflows. So I guess that's a point for Java.

Conclusions of the arguments so far (still open for discussion of course):
  • C and C++ are faster and much more memory-efficient than Java.
  • C++ is more flexible than C and Java.
  • There is no real difference in the ease of debugging between C++ and Java (though they are probably both easier than C because of higher modularity).
  • Java is safer than C++ and C++ is safer than C.

Although Java is still not the safest language around, it might be the case that there is no other language that is both at least as fast and at least as safe; and that's enough for Java to be a valuable addition to the spectrum (I think). If we don't consider Groovy, at least.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: Java vs C/C++

Postby Berengal » Wed May 05, 2010 5:19 pm UTC

Jplus wrote:Although Java is still not the safest language around, it might be the case that there is no other language that is both at least as fast and at least as safe
Let me just post a link (and note that Haskell has dropped somewhat in speed lately, possibly because their benchmarking method has changed.)
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

User avatar
Jplus
Posts: 1709
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Java vs C/C++

Postby Jplus » Wed May 05, 2010 5:36 pm UTC

Berengal wrote:
Jplus wrote:Although Java is still not the safest language around, it might be the case that there is no other language that is both at least as fast and at least as safe
Let me just post a link (and note that Haskell has dropped somewhat in speed lately, possibly because their benchmarking method has changed.)

If you read the information from the benchmarking game website, it appears like they wouldn't change their benchmarking method that soon. All they do for updating is switching to newer hardware once in a few years, switching to newer implementations of the languages, and switching to faster implementations of the benchmarking algorithms if they become available. So if Haskell is now slower compared to Java than it was before, that's most likely because somebody submitted a faster Java implementation or because the Java implementation has become faster.

As it is, it appears Haskell is not "at least as fast as Java", but rather slower in the same order of magnitude that Java is slower than C++. Groovy might be both at least as fast and at least as safe as Java, though.
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
TheChewanater
Posts: 1279
Joined: Sat Aug 08, 2009 5:24 am UTC
Location: lol why am I still wearing a Santa suit?

Re: Java vs C/C++

Postby TheChewanater » Wed May 05, 2010 7:50 pm UTC

0xBADFEED wrote:It's not that C++ "supports an unsafe technique" it's that the unsafe mode of operation is the default. The C++ standard didn't even include a decent smart pointer until tr1. Then there's Boost. Boost is great but it didn't really come along until 2001 or so and at that point people had already been writing C++ for nearly a decade. Chances are good that in a C++ project you will be using code from this era.

And Java code from that era was any good?
ImageImage
http://internetometer.com/give/4279
No one can agree how to count how many types of people there are. You could ask two people and get 10 different answers.

0xBADFEED
Posts: 687
Joined: Mon May 05, 2008 2:14 am UTC

Re: Java vs C/C++

Postby 0xBADFEED » Wed May 05, 2010 11:58 pm UTC

TheChewanater wrote:And Java code from that era was any good?

There's a lot less of it and it tends to be easier to work with than C++ code from that era.

User avatar
Jplus
Posts: 1709
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Java vs C/C++

Postby Jplus » Thu May 06, 2010 1:59 pm UTC

0xBADFEED wrote:
TheChewanater wrote:And Java code from that era was any good?

There's a lot less of it and it tends to be easier to work with than C++ code from that era.

Or at least it will generally be somewhat safer (which I think was the real point at stake).
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
Jplus
Posts: 1709
Joined: Wed Apr 21, 2010 12:29 pm UTC
Location: Netherlands

Re: Java vs C/C++

Postby Jplus » Fri May 07, 2010 9:51 pm UTC

Two updates: one on the benchmarking game and one on functional programming in C++.

Benchmarking: Berengal had well seen that Haskell can be as fast as Java. The problem is that the benchmarking game is polymorphous with respect to the use of the processor, and there is no simple way to switch between the options:
Now there are two interesting observations. On the one hand, in the single-core benchmarks Haskell is about as fast as Ada, while in the quad-core benchmarks it performs more like C# (which is slower). Maybe Haskell is less able to profit from multithreading. On the other hand, in the 32-bits benchmarks Ada is only about half as fast as Java, while in the 64-bits benchmarks it's about equally fast. Apparently Java doesn't profit from the 64-bits architecture while Haskell and Ada do. So it happens that in the 64-bits single-core benchmarking, Haskell is as fast as Java! Although this result is probably still not enough to maintain that Haskell is at least as fast as Java, considering the obvious disadvantage in multithreading.

For Ada however it is a very different story. Ada is a more obvious competitor to Java and C++ anyway because of its more real-worldish imperative focus. If we base our conclusions only on the 64-bits benchmarks and online sources, we can extend them to the following:
  • speed: C++, C > Java, Ada
  • memory efficiency: C++, C > Ada >> Java
  • flexibility: C++ >= Ada > Java >= C
  • safety: Ada > Java > C++ > C
  • support for concurrent programming: Ada > Java
  • they all take about the same amount of code to get things done.
Is Ada a language which has advantages compared to Java, but no disadvantages? (And is it appropriate to discuss that in this thread?)


Functional programming in C++: I wasn't very well able to defend C++' declarative faculties earlier on, because I wasn't familiar with functional programming concepts. However, yesterday and today I've dived into Haskell properly and I encountered several aspects of functional programming that are also represented in C++. Here they come, in random order:
  • Closures are supported as function objects (i.e. instances of classes with overloaded operator() ). Normal functions can also be passed around with pointers (which is also possible in C), but at best that's a very limited kind of closure that must be stateless.
  • Currying and function composition are supported through various function and class templates in the standard library <functional>.
  • Equivalents to the very essential functions like "foldr", "map" and "zipWith" in Haskell are present in the standard libraries <algorithm> and <numeric> (the latter of which is by no means necessarily numeric at all).
  • Lambda expression are introduced in C++0x.
  • Automatic type deduction is also introduced in C++0x, which will make currying and function composition a lot more convenient (currently it takes quite a lot of typedefs in some cases to let it remain readable and typeable).
  • C++0x will have explicit move semantics (now already implicitly implemented by most compilers as a optimization strategy), which is necessary to cope efficiently with functions that return a stack-allocated object (which is semantically speaking the default in functional programming).
"There are only two hard problems in computer science: cache coherence, naming things, and off-by-one errors." (Phil Karlton and Leon Bambrick)

coding and xkcd combined

(Julian/Julian's)

User avatar
Berengal
Superabacus Mystic of the First Rank
Posts: 2707
Joined: Thu May 24, 2007 5:51 am UTC
Location: Bergen, Norway
Contact:

Re: Java vs C/C++

Postby Berengal » Sat May 08, 2010 1:01 am UTC

The multithreading issue is a bit weird, since it's not very long ago Haskell used to trounce the others in that area. The Thread Ring benchmark showed Haskell being twice as fast as the second fastest language, Erlang, five times as fast as C and about three orders of magnitude faster than the slowest languages (except Ruby, which timed out). Something changed, but I don't know what. I suspect the benchmarking method changed (everyone uses schedulers now but it used to be you had to use native threads if your language implementation didn't have a built-in scheduler), and possibly there's a regression in the most recent GHC versions. I've not looked into it, but massive multithreading (either many threads, or using all cores) in GHC seems to have become a somewhat fragile. There was a bug on Linux before where using a number of worker threads less than the number of cores you had worked well, but anything equal or more would show drastic slowdowns. Perhaps they broke something trying to fix that...
It is practically impossible to teach good programming to students who are motivated by money: As potential programmers they are mentally mutilated beyond hope of regeneration.

qbg
Posts: 586
Joined: Tue Dec 18, 2007 3:37 pm UTC

Re: Java vs C/C++

Postby qbg » Thu May 13, 2010 2:07 pm UTC



Return to “Religious Wars”

Who is online

Users browsing this forum: No registered users and 5 guests