Java vs C++

[Joshua Cranmer]

Really??

You trimmed the part where he elaborated on what that phrase meant.

 

[Arved Sandstrom]

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.

You make "corporate" software sound like a niche market. Yeah, software
for business and governments is such a little category, ain't it.

Very few mass-market or open-source apps are
written in those languages, for example.

Holy ****. You're officially completely detached from reality.

[ SNIP ]
AHS

 

[Esmond Pitt]

The Java designers wanted everything that C++ templates offered.

It should be obvious from the design that they wanted a great deal more
than that. They wanted a coherent type system for a start, which C++
templates don't have, and they wanted compile-time safety, which
*requires* a coherent type system. That's what all the T super X and T
extends Y stuff is for - so the compiler can do type algebra. None of
this appears in C++ whatsoever.

It is totally and utterly wrong misleading to think of Java Generics and
C++ templates as similar. They are really polar opposites. C++ templates
generate new types. Java Generics restrict existing types.

 

[Arne Vajhøj]

The Java designers wanted everything that C++ templates offered. The only
parts they omitted were the ones they couldn’t have.

Why do you think that?

They implemented something very different.

Arne

 

[Arne Vajhøj]

Not at all. The reason is exactly as already stated, namely that people
seem to assume that the linker has no intelligence, or that there is a
linker in first place. Nevertheless, the C++ standard doesn't even
define linking, and the world is no longer that simple. Thus, I still
don't see how this argument applies. Surely the C++ world works
different from the java world, but saying that there is no duplicate
code in Java or that there is always code duplication in C++ is surely
wrong.

It how the simple implementations do it.

It is what the common implementations do it.

What various super smart optimizers may do is pretty
far fetched.

Arne

 

[Arne Vajhøj]

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.

C++ templates are like many other C++ features very powerful.

You can create some very elegant solution or make a big hole
in your foot with it.

Arne

 

[Arne Vajhøj]

That’s right, I forgot there is no “standard spec†for Java, it is simply
what Sunacle says it is.

What do you think the S in JLS stands for?

Not too much that you can’t write portable code in it.

Real C apps that will run predictable on any platform is
pretty rare.

Real C apps that support a wide range of platforms via
ifdef's are common.

C apps that the programmer think is portable but is not
are also common.

Arne

 

[Arne Vajhøj]

Not really. Sticking to standard POSIX types like size_t, time_t etc gets
you a lot of the way there.

POSIX does not cover all aspects.

And not all platforms are POSIX compliant.

Arne

 

[Arne Vajhøj]

Absolutely correct. It is very easy to write potentially broken C++
programs that run perfectly fine on a certain architecture compiled with
a certain C++ compiler using a certain set of compiler options.

Bad programs may depend on different types of invalid assumptions. To
name a few: assume sizeof(T)==sizeof(U), assume char is signed/unsigned,
assume bitfields are signed/unsigned, make assumptions about struct
alignment.

For certain APIs (MS Windows conatins lots of them) struct layout
assumpations are essential. Since there was no standard way of
expressing such assumtions code could easily break just by changing some
compiler options. For that reason, each C++ distro came with its own
Windows header files.

Perhaps things have improved since I moved away from C++ in '99.

The current C and C++ standards are from 99 and 98, so not
that much has changed.

I think that compiler support for the standards has improved some.

Arne

 

[Arne Vajhøj]

But the Java rule is the limitation now.

I think everybody agrees with that.

Arne

 

[Joshua Cranmer]

The Java designers wanted everything that C++ templates offered. The only
parts they omitted were the ones they couldn’t have.

No, it is very possible to have fully implemented C++ templates. As C++
templates are basically a semantically-aware macro processor whose code
is created at instantiation as opposed to definition, you just have to
generate the class files at template instantiation as opposed to class
definition. That basically boils down to "twiddle a few bits in the
class file", so it's no more invasive than generics was.

If you argue that wasn't an option because they didn't want to rewrite
the collections API (which .NET decided to do), it's still possible to
leverage roughly the same effect with more invasive modifications to the
bytecode. You can get reified types by creating a new method info
structure which captures the generic arguments passed into the method
(for constructors, this would be the generic class passed in), which you
could store in an appropriate synthetic variable. You could even get the
duck typing nature of templates with invokedynamic (well, it wouldn't
work for primitive types, but generics already through those out the
window).

They could have had all of C++ templates. Clearly, they did not feel the
benefits of full template support would be worth the cost of implementation.

 

[Lawrence D'Oliveiro]

It is 8086 architecture not 80286 architecture.


Windows has nothing to do with CPU architecture.

DOS/Windows is the only reason 8086/80286 segmented architectures became
popular.

 

[Lawrence D'Oliveiro]

For certain APIs (MS Windows conatins lots of them) struct layout
assumpations are essential.

POSIX manages such things in a portable way. Windows not only doesn’t, it
manages to saddle Win64 APIs with all kinds of 32-bit compatibility baggage
from Win32.

 

[Lawrence D'Oliveiro]

Without ifdef's ????

Relevance being?

anywhere not everywhere

Is Java for anyone, or everyone?

 

[Lawrence D'Oliveiro]

What do you think the S in JLS stands for?

Not “standardâ€.

Real C apps that will run predictable on any platform is
pretty rare.

Really?? We have them coming out our ears. I have thousands of them
installed on my system alone. Let’s see, the Linux kernel, 15 million lines
of source code, almost entirely in C, portable across about two dozen
different major processor architectures. GCC, Apache, Python, Blender (a
million lines of C, plus about 220 thousand lines of C++), Gimp ... the list
goes on and on.

 

[Lawrence D'Oliveiro]

POSIX does not cover all aspects.

Well, you need tools like autoconf as well to handle the more complicated
cases.

And not all platforms are POSIX compliant.

All the ones worth using are.

 

[Arne Vajhøj]

Relevance being?

That it is not portable - it just support a number of platforms.

Is Java for anyone, or everyone?

The slogan used "anywhere".

(which is why the acronym is WORA not WORE)

Arne

 

[Lawrence D'Oliveiro]

You trimmed the part where he elaborated on what that phrase meant.

You mean, where he explained “generate†didn’t mean “generateâ€, or “source
code†didn’t mean “source code�

Black is white. Let me alaborate on that: no it isn’t.

 

[Arne Vajhøj]

DOS/Windows is the only reason 8086/80286 segmented architectures became
popular.

That does not make Windows part of the CPU architecture.

Arne

 

[Esmond Pitt]

DOS/Windows is the only reason 8086/80286 segmented architectures became
popular.

Another blanket statement ex cathedra.

That's not what the guys at Intel think, or the guys at Motorola either.
They will tell you that despite its ugliness at the point of code
generation the Intel segmented architecture yielded very significant
cost and performance benefits that basically drove Motorola out of the
market.