Java vs C++

[Lew]

Joshua Cranmer wrote

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

Or, in the US, the same thing for a 10-digit number.

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

 

[Lew]

The big way in which Java is tied to 32 bit architectures is not in the
simple data types. It is the maximum size of an array, String, Set, List
etc.

I wouldn't say "tied to a 32-bit architecture" but "subject to a 32-bit
limitation". The limitation for Java is the same on any architecture. But I
take your meaning.

It is possible with current Java implementations to write a collection like
List that is not subject to the 32-bit limit, so arguably the fault for the
java.util.List limit lies not with Java itself but the API.

It would require a language change to implement an array with
larger-than-32-bit addressing, but the use case for that is narrow enough that
an API construct should serve, obviating the need for a language change.

At least for a while. I imagine that once we are unphased by exbibyte RAM
structures we can change the language.

Assuming the world hasn't all switched over to C++ by then.

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

 

[Mike Schilling]

Joshua Cranmer wrote



Or, in the US, the same thing for a 10-digit number.

That too.

 

[Arne Vajhøj]

I am aware of one issue in the simple data types that reflects 32 bit
architecture, JLS section 17.7, "Non-atomic Treatment of double and long".

It is somewhat related, but 32 bit architectures could
operate on 64 bit data (VAX does) and it could be implemented
atomicly.

The big way in which Java is tied to 32 bit architectures is not in the
simple data types. It is the maximum size of an array, String, Set, List
etc.

Yep.

Arne

 

[Arne Vajhøj]

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.

Java generics are useful for more than containers.

It just get complex when used for more than containers.

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.

Joshua did not claim otherwise.

Arne

 

[Arne Vajhøj]

Java starts out with static typing, then devotes an awful lot of effort to
wiggling its way out of that. Look at “unchecked conversionsâ€, for example.

Wouldn’t it be simpler not to pretend in the first place?

????

I think unchecked conversion is a static typed features as well.

Arne

 

[Arne Vajhøj]

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

No. Same code.

The only time they become the
same thing is in “erasures†and “raw typesâ€,

Since Java generics are always type erasured, then "the only time"
is actually "every time".

But .NET does not due type erasure and still only have one copy
of the code for generics.

Same sort of thing in C++.


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

Because beginners that just used the generic containers would not
see the big difference.

And those needing to do more advanced stuff where the difference
becomes visible is expected to read about generics.

Arne

 

[Lawrence D'Oliveiro]

I am aware of one issue in the simple data types that reflects 32 bit
architecture, JLS section 17.7, "Non-atomic Treatment of double and long".

The big way in which Java is tied to 32 bit architectures is not in the
simple data types. It is the maximum size of an array, String, Set, List
etc.

Also in the fact that array subscripts cannot be long.

 

[Lawrence D'Oliveiro]

In that flamewar, someone estimated the size of Clojure's documentation
by browsing its website and counting pagedown keypresses needed to reach
the bottom of each web page.

Funny, I did the same thing for Python, just for comparison
<http://docs.python.org/py3k/reference/>. The figure I came up with for that
Language Reference was 92 pages. To be fair, I suppose you should include
the first 6 chapters of rhe Library Reference
<http://docs.python.org/py3k/library/>, which is another 69 pages, for a
total of 161.

For comparison, I have a couple of draft C99 specs floating around. They
total 550 pages, until you realize most of that is section 7, the standard
library. Leave that out, and you end up with 163 pages.

 

[Lawrence D'Oliveiro]

On 02/05/2011 10:38 PM, Lawrence D'Oliveiro wrote:
... 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.

No. Same code.

Same code in C++ too, then.

 

[Lawrence D'Oliveiro]

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.


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


It's not the same syntax. List<String> is the type of a specific
instance, while the class still remains List.

List<String> is a class, not an instance. In something like

List<String> L;

it is L that is the instance.

See, how can you try to tell me what the difference is between Java and C++,
when you don’t understand it yourself?

 

[Lawrence D'Oliveiro]

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.

Why does Java impose such a pointless restriction?

 

[Lawrence D'Oliveiro]

Strange that Java never copied the C++ operator names "andâ€, “or†and “notâ€.

 

[Thomas Richter]

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?

Who said this, and where? I did not mean to say this implication. Java
often took the path of providing a more accessible language than C++,
maybe for good reasons since C++ has quite some complexity. But
templates are not generics, and I'm not aware that you can use them for
metaprogramming. Whether you *want* to use metaprogramming, well, that's
a different question.

So long,

Thomas

 

[Thomas Richter]

Java generics are useful for more than containers.

It just get complex when used for more than containers.

Well, I didn't mean to say something else (see, I wrote "mostly", not
"only"), but nevertheless, could you provide an example?

Joshua did not claim otherwise.

This was at least worded in a very misleading way.

So long,
Thomas

 

[Thomas Richter]

No. Same code.

I don't know in how far "same code" makes sense in Java in first place.
The code that is created depends entirely on the JIT, and it may or may
not generate the same code depending on how often it is called. For
example, if it the JIT "sees" that the code is called with one specific
type most of the time, it could create separate code just for this
purpose and hence omit the type checks. And in C++, a compiler can also
merge template instances because they are identical, i.e. function
alike, i.e. for example they all operate on pointers.

Thus, I don't really see how that type of argument applies.

Not really. Generics are run-time checked, templates are compile-time
checked. There is no "ClassCastException" in C++. If the class doesn't
fit, the compiler will tell at compile time. Otherwise, the code will
crash at run time - there is no additional check inserted as it is in
java which tests whether the type-erased instance is of the proper type.

Greetings,
Thomas

 

[Lawrence D'Oliveiro]

Java is very widely used for network and business applications, and web
apps, these days ...

I was trying to make sense of where you were coming from with your
predictions, and then I realized—you’re primarily talking about corporate
development. Because that’s just about the only place languages like Java
and C#/Dotnet get much use. Very few mass-market or open-source apps are
written in those languages, for example.

Except, of course, for Android. Which is why I’m here.

 

[Lawrence D'Oliveiro]

There is no "ClassCastException" in C++.

Yes there is. It’s called “bad_castâ€. Where do you think Java got the idea
from?

 

[javax.swing.JSnarker]

Yes there is. It’s called “bad_castâ€. Where do you think Java got the idea
from?

dynamic_cast<foo>(bar) can throw this if bar is not really a foo. But
C++ lets you use the unsafe old (foo)bar cast from C, and if bar is not
really a foo, welcome to undefined behaviorville.

Java doesn't let that happen: the cast syntax is (Foo)bar but the
semantics is that of dynamic_cast: bar is a Foo or an exception gets thrown.

The only way to come close to C's unsafe cast with Java is to muck about
with serialization, to alter a serialized representation of a Bar to
claim to be of class Foo instead and then deserialize it. Most likely
you get a broken Foo and exceptions thrown, but not a VM crash. The main
reason you'd try that is to try to break some existing Java program --
hack it, crack it, virus someone's VM. There's never any use for that in
normal programming that I am aware of.

--

 

[Helium Balloon]

Except, of course, for Android. Which is why I’m here.

Shouldn't you be off watching football, or something?