Java vs C++

[Lawrence D'Oliveiro]

My copy of the C++0x draft reference standard, i.e. the copy sent out
for a ballot by national bodies, consisted of no fewer than 1300
numbered pages.

Yeah, so C++ continues to leap ahead into even greater complexity.

Also take into consideration the fact that the C++ standard does not try
to pin stuff down into unambiguous interoperable statements, e.g., a
precise size definition for size_t.

It seems to me that’s another drawback of Java, that it explicitly defines
the sizes of things from the viewpoint of 32-bit architectures like those
current in the 1990s. Some of those decisions look less wonderful on current
64-bit architectures.

So 684 pages of well-written, easily-understood text ...

Not quite so “well-written, easily-understoodâ€, as I have pointed out
elsewhere. The mistakes seem particularly concentrated in the parts
describing the newer language features.

 

[Lawrence D'Oliveiro]

... templates and gener[ic]s are completely different beasts.

“Completely†as in “having nothing in common� Or is this some usage of
“completely†that I wasn’t aware of?

Please explain.

Templates in C++ are basically advanced macros--each invocation of a
template type regenerates the class, so a Foo<int> and a Foo<double> are
two completely different things.

They are different things in Java as well. The only time they become the
same thing is in “erasures†and “raw typesâ€, which are backward-
compatibility mechanisms introduced to avoid breaking existing code that
doesn’t know about generics. The use of the name “Foo†without parameters is
explicitly deprecated, with a bold warning that says it may go away in the
future, you have been warned.

And then, of course, the language goes on to use exactly that deprecated
syntax as the recommended way of accessing static members.

(Exercise for the reader: it turns out there’s another way of accessing
static members. But that’s deprecated as well. What is it?)

Generics in Java are basically compile-time syntactic sugar to ensure
type-safety of container types at compile time instead of waiting until
you hit the code at runtime to get that dreaded ClassCastException.

Same sort of thing in C++.

About the only thing they share in common is the syntax ...

Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it
reuse exactly the same syntax?

 

[Joshua Cranmer]

They are different things in Java as well.

The hell they aren't. In Java, there is only one instance of
LinkedList::add(T object). In C++, there are as many instances of
std::list<T>::front as times you use it.

Try, for example, implementing both List<String> and List<Character> in
the same class. Java will tell you that you cannot do it. C++, on the
other hand, wouldn't bat an eye.

The only time they become the
same thing is in “erasures†and “raw typesâ€, which are backward-
compatibility mechanisms introduced to avoid breaking existing code that
doesn’t know about generics.

I think Java would likely have gone with much the same syntax even if
generics had been introduced in the beginning.

And then, of course, the language goes on to use exactly that deprecated
syntax as the recommended way of accessing static members.


Yeah, funny that. If Java didn’t want to be seen as copying C++, why did it
reuse exactly the same syntax?

Propose a different syntax for Java generics. Note that it cannot be
syntactically ambiguous with any other Java construct, and that, since
it will be used a fair amount, it must be on the shorter side. There
aren't many characters you can really use; < and > are about the only
thing that fits the bill.

 

[Joshua Cranmer]

It seems to me that’s another drawback of Java, that it explicitly defines
the sizes of things from the viewpoint of 32-bit architectures like those
current in the 1990s. Some of those decisions look less wonderful on current
64-bit architectures.

I would venture a guess that most C or C++ code isn't as easily portable
to 64-bit platforms as you would think, since people make assumptions
about the sizes of various types. If you don't define de jure type
sizes, people will follow the de facto standards (i.e., 32-bit) and will
then get horrible breakages when the platform it runs on does not match
the standards.

Also, I might add, the main benefit 64-bit holds right now is the
increased access to memory space, i.e., 64-bit addressability of
pointers. Since Java does not let you manipulate pointer addresses
directly, the implementation is easily able to adjust the size of an
Object pointer and still conform to the specification. So you basically
get access to as much memory as your host will allow without the messy
bits about the size of integral operands being essentially undefined.

Not quite so “well-written, easily-understoodâ€, as I have pointed out
elsewhere. The mistakes seem particularly concentrated in the parts
describing the newer language features.

If you think it is so difficult to understand, you must not have voyaged
deeply into the world of specifications. Java is easily understandable
compared to some of the stuff I've read.

 

[Lew]

Hello Lew,

You are correct, templates are a completely different thing. However, since
they try to achieve a similar goal (albeit in very different ways) they are
often compared and spoken of in combination.

I suspected he is trolling also but could not resist correcting a false
statement.

That's funny, because the statement wasn't false and you didn't correct it.
You even said it was correct.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Silvio]

That's funny, because the statement wasn't false and you didn't correct
it. You even said it was correct.

Lawrence said "C++ had this from the beginning" referring to Java having
added generics afterwards. That was a false statement.

I pointed out that in C++ this was also a later addition. I just made
the mistake of referring to templates as generics.

 

[Silvio]

Yeah, so C++ continues to leap ahead into even greater complexity.


It seems to me that’s another drawback of Java, that it explicitly defines
the sizes of things from the viewpoint of 32-bit architectures like those
current in the 1990s. Some of those decisions look less wonderful on current
64-bit architectures.


Not quite so “well-written, easily-understoodâ€, as I have pointed out
elsewhere. The mistakes seem particularly concentrated in the parts
describing the newer language features.

Oh, I remember how well C++ and its undefined sizes of things served us
when we had to port heaps of code from 16-bit to 32-bit.

 

[Arved Sandstrom]

On 11-02-06 12:39 AM, Ken Wesson wrote:
[ SNIP good overview ]

In reality, Java's static types and checked exceptions will throw a fair
amount of syntactic salt into this, barring a hefty (and again Haskell-
like) infusion of type inference. Java could lose out in the long run to
JVM hosted languages designed to be functional from the ground up. Of
these the frontrunners seem to be Clojure and Scala, with Scala's non-
Lispy syntax giving it an edge in familiarity (and especially with
management) and Clojure's macros (and consequent ability to reify
boilerplate patterns into things you can name and call and not
reimplement over and over again) giving it an edge in expressivity.

Both are gaining traction even with management types, especially when
stuff coded in them can be bundled into jars and deployed on application
servers in a manner identical to deploying Java code. It doesn't look or
feel any different to management than deploying Java; the coders are
pushing different symbols around in their text editors and IDEs but
they're still using IDEA or NetBeans or Eclipse and still producing .jar
files that behave the same way when put on the server. So if the coders
are typing stuff that looks incomprehensible in a different way than it
did before, and seem a bit happier, and are suddenly making their
deadlines instead of missing them, and nothing has stopped working or
started working differently at a level management notices, management
won't rock the boat. At most they'll want to be assuaged about
intellectual property rights, mainly that a) the company still owns its
code and b) they aren't going to get sued for using this stuff. Both
languages in question have, if anything, less stringent license
requirements than Java itself.

[ SNIP ]

I'm currently pushing Scala (nothing against Clojure really, I am just
considerably more familiar with Scala) quietly, in-house and also on
some client projects, with similar thinking in mind. It _is_ a fact that
management truly doesn't care that this chunk of opcodes was originally
Java source, and that other chunk of opcodes was originally Scala
source. If a project development team can incrementally introduce user
libraries into a Java EE environment that happen to be written in Scala,
and they are developed faster and we end up with more reliable code,
nobody is going to complain.

AHS

 

[Arved Sandstrom]

Yeah, so C++ continues to leap ahead into even greater complexity.


It seems to me that’s another drawback of Java, that it explicitly defines
the sizes of things from the viewpoint of 32-bit architectures like those
current in the 1990s. Some of those decisions look less wonderful on current
64-bit architectures.


Not quite so “well-written, easily-understoodâ€, as I have pointed out
elsewhere. The mistakes seem particularly concentrated in the parts
describing the newer language features.

You haven't actually pointed out any mistakes. Now, if your intent is to
point out parts of the JLS that you find hard to understand, and your
argument is that if _you_ are having problems then so are many others,
then a more productive approach would be (1) to phrase it that way, and
(2) offer a suggestion or two that you think is better. But you haven't
located any flat-out mistakes yet.

I find the various versions of the JLS to be considerably better than
most other language or API specs I've had to wade through.

AHS

 

[Arne Vajhøj]

It seems to me that’s another drawback of Java, that it explicitly defines
the sizes of things from the viewpoint of 32-bit architectures like those
current in the 1990s. Some of those decisions look less wonderful on current
64-bit architectures.

There are nothing in defining the size of the simple data types
that are tied to 32 bit architecture.

Why shoudl 8, 16, 32 and 64 bit integers be more 32 bit than
64 bit centric??

Not quite so “well-written, easily-understoodâ€, as I have pointed out
elsewhere. The mistakes seem particularly concentrated in the parts
describing the newer language features.

As far as I have seen all your so called mistakes is not problems
in the JLS but you not understanding the text, because you have
started reading the JLS without starting with a very basic tutorial
about Java.

Arne

 

[Arne Vajhøj]

I would venture a guess that most C or C++ code isn't as easily portable
to 64-bit platforms as you would think, since people make assumptions
about the sizes of various types. If you don't define de jure type
sizes, people will follow the de facto standards (i.e., 32-bit) and will
then get horrible breakages when the platform it runs on does not match
the standards.

My guess is that most portable C/C++ not using the C99 typedefs
have their own similar ifdef'ed typedefs.

Arne

 

[Arne Vajhøj]

I'm currently pushing Scala (nothing against Clojure really, I am just
considerably more familiar with Scala) quietly, in-house and also on
some client projects, with similar thinking in mind. It _is_ a fact that
management truly doesn't care that this chunk of opcodes was originally
Java source, and that other chunk of opcodes was originally Scala
source. If a project development team can incrementally introduce user
libraries into a Java EE environment that happen to be written in Scala,
and they are developed faster and we end up with more reliable code,
nobody is going to complain.

Scala is doing pretty well.

It seems to be by far the most successful functional language.

Among publicly know Scala users are the British newspaper
Guardian and EDF Trading.

Arne

 

[Thomas Richter]

Templates in C++ are basically advanced macros--each invocation of a
template type regenerates the class, so a Foo<int> and a Foo<double> are
two completely different things.

That's much more than a macro could do. Templates are a language of its
own, include syntax checks, etc. Quite unlike macros, they do not
substitute text patterns. Templates allow meta-programming, i.e. you can
use the compiler to generate code. And, of course, templates are quite
complex - very unlike the simple-minded preprocessor.

Generics in Java are basically compile-time syntactic sugar to ensure
type-safety of container types at compile time instead of waiting until
you hit the code at runtime to get that dreaded ClassCastException.

Well, java had to take the route of type-erasure to allow generic
progamming plus type checks because it wasn't part of the language to
begin with, so it was "hacked" into the specs more or less. Generics are
considerably less powerful, but also considerably easier than C++
templates. There's no metaprogramming with generics, and generics are
mostly limited to containers which does not hold for C++ templates. They
are quite different.

About the only thing they share in common is the syntax, and even then,
C++ didn't allow A<B<C>> until C++0x (which, according to Bjarne
Stroustroup, took a bit of work to convince compiler vendors to accept).

I beg your pardon? C++ allows nested templates since C++99 and before.
The only issue here is a notational one, namely that you had to write
A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
token (shifting, namely). That is the only thing that got fixed in
C++0x, not nesting templates which is part of the language since C++99.

 

[Thomas Richter]

The hell they aren't. In Java, there is only one instance of
LinkedList::add(T object). In C++, there are as many instances of
std::list<T>::front as times you use it.

I would say that's an implementation detail. A compiler/optimizer could
check how many different implementations are needed and could merge
those that are identical.

Besides that, where you use an object in java, one would use a pointer
or a reference in C++, and hence the code would be identical, allowing a
good compiler to merge the implementations. C++ and java are quite
different in their tradition how to use types, or what types are. Java
has two sorts of types: First class citizens like int or double that are
copied, and second class citizens like classes that are referenced. C++
doesn't have that, objects are objects and ints and classes are handled
alike.

Try, for example, implementing both List<String> and List<Character> in
the same class. Java will tell you that you cannot do it. C++, on the
other hand, wouldn't bat an eye.
True.


I think Java would likely have gone with much the same syntax even if
generics had been introduced in the beginning.

That's really a speculation. One could also speculate that if java would
have used or required generics from the beginning, they would be closer
to C++ templates and would not use type erasure; instead, they would be
parametrized classes as they are in C++. It's really speculation.

Greetings,

Thomas

 

[Mike Schilling]

I beg your pardon? C++ allows nested templates since C++99 and before. The
only issue here is a notational one, namely that you had to write A<B<C> >
(note the space behind B<C>) to avoid >> being parsed as a token
(shifting, namely). That is the only thing that got fixed in C++0x, not
nesting templates which is part of the language since C++99.

This surprises me. Given all the difficult parsing needed to make sense of
C++, it seems like this small bit of lexical analysis should never have been
a sticking point.

 

[Lew]

Lawrence said "C++ had this from the beginning" referring to Java having added
generics afterwards. That was a false statement.

I pointed out that in C++ this was also a later addition. I just made the
mistake of referring to templates as generics.

Oh - *that* false statement. Yes, you were right to correct it.

C++ has never had generics, and it did not have templates from the beginning.
You are right.

I am convinced that "Lawrence" is a troll.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Joshua Cranmer]

That's much more than a macro could do. Templates are a language of its
own, include syntax checks, etc. Quite unlike macros, they do not
substitute text patterns. Templates allow meta-programming, i.e. you can
use the compiler to generate code. And, of course, templates are quite
complex - very unlike the simple-minded preprocessor.

It is the code generation that I'm referring to as "an advanced macro".
It's a macro generator that understands types and is heavily integrated
with the syntax of C++, but it is basically a way to automatically
generate code.

I beg your pardon? C++ allows nested templates since C++99 and before.
The only issue here is a notational one, namely that you had to write
A<B<C> > (note the space behind B<C>) to avoid >> being parsed as a
token (shifting, namely). That is the only thing that got fixed in
C++0x, not nesting templates which is part of the language since C++99.

I was specifically referring to the ability to use >> instead of > >.

 

[Joshua Cranmer]

This surprises me. Given all the difficult parsing needed to make sense
of C++, it seems like this small bit of lexical analysis should never
have been a sticking point.

When Bjarne Stroustrup gave a talk about C++0x to my university, one of
the things he said was it took him several tries to get the compiler
vendors to agree to support that minor lexical analysis. The only way he
could convince them to do it was to point out that all the major
compilers basically had an error message in that case which said "add a
space, idiot", so all they had to do was remove that error message.

 

[Lew]

We could end this entire thread right now by conceding that, yes, C++ is
clearly the superior language over Java, just like Esperanto is over English,
unless, of course, you actually want to accomplish something, but all
analogies break down somewhere, right?

Anyway, just tell the OP that he's right, C++ is wonderful and Java is crap,
and all those thousands more Java jobs out there can go to those of us
impurists. C++ invented everything and Java is a poor stepchild, and if
imitation is the sincerest form of flattery then Java just gave C++ the
finger. He's right, we're wrong - he need learn nothing new and we praise him
with angels' song and rose petals.

C++ rules, Java drools!

Can we stop talking about C++ now? You know it only makes us poor
stepchildren embarrassed and to feel clumsy, contemplating how much worse our
language of choice is than the One True Way, so stop rubbing our noses in it,
please. Let's just talk about Java as Java so we may be shielded from the
blinding light of knowledge of our insignificance compared to those of the C++
world. Leave us benighted souls to our dark Java Hades and burn us not with
the C++ Sun!

Again, C++ rules, Java drools! Done. QED. You win. Move on.

--
Lew
Ceci n'est pas une fenêtre.
..___________.
|###] | [###|
|##/ | *\##|
|#/ * | \#|
|#----|----#|
|| | * ||
|o * | o|
|_____|_____|
|===========|

 

[Mike Schilling]

When Bjarne Stroustrup gave a talk about C++0x to my university, one of
the things he said was it took him several tries to get the compiler
vendors to agree to support that minor lexical analysis. The only way he
could convince them to do it was to point out that all the major compilers
basically had an error message in that case which said "add a space,
idiot", so all they had to do was remove that error message.

Like when you call a 9-digit number and the phone tells you that you need to
dial a 1 first.