Java vs C++

[Arne Vajhøj]

POSIX manages such things in a portable way.

No.

POSIX does the same thing as Windows.

Use compiler specific header files to get the correct
physical layout.

(POSIX uses fewer structs than Windows, but ...)

Arne

 

[Lawrence D'Oliveiro]

The fact remains that this is irrelevant to the discussion.

The fact remains, the poster said “There is no "ClassCastException" in C++â€,
which I understood to mean “There is no equivalent to "ClassCastException"
in C++â€, which is wrong.

Templates aren't used like this in C++ ...

Templates are orthogonal to the business of class casts.

... and the C++ compiler doesn't insert a type check into the binary to
see whether the types match.

It does for the C++ equivalent to the Java subclass cast.

Besides, dynamic_cast<> only throws if the involved objects have virtual
functions, and thus have run time type information available, and the
types are not compatible.

I went over section 5.2.7 “Dynamic cast†of the C++ standard very carefully,
and I can find no such proviso. It’s only a page and a half, so I think it’s
unlikely I missed anything.

Have a look for yourself and see if I’m right or wrong.

 

[Lawrence D'Oliveiro]

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

In that case, they went backwards. Because the whole “raw types†concept
detracts from and weakens the coherence of the 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.

What one hand giveth, the other taketh away...

 

[Arne Vajhøj]

Not “standardâ€.

specification

It is the specification for Java.

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.

No. I don't think many of those apps are portable C. Most likely
none of them are. Those apps are just ported to a number of platforms.
Ported by someone adding #ifdef sections etc. to make them work
on a specific platform.

Arne

 

[Arne Vajhøj]

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

The existence of that tool is an indication that there is a
portability problem.

But autoconf does not solve all problems.

All the ones worth using are.

Well - I don't think anyone defines portability as
running unchanged on the platform one specific
person considers worth using.

Arne

 

[Lew]

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.

Intel brought quite a few innovations in quite early, many of which went
nearly unnoticed for a while. The '286 and up have privilege rings and
support for multitasking in the hardware, for example. Only a couple of OSes
really used that stuff back then.

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

 

[Wojtek]

Joshua Cranmer wrote :

Why should it have? They're just aliases for other objects. By your
reasoning, Java should also have copied the C trigraphs or the other tokens
in the "Alternative tokens". You know, for the three people in the world who
do not have { on their keyboard.

Actually trigraphs are more for environments that do not have []^~ and
a few other characters in their character set. Such as IBM mainframe
OSs.

I had to write a standard C to IBM mainframe converter a few years ago
(yikes, 1990!). Things like variable names need to be upper case, limit
of 8 characters for variables, methods, etc.

 

[Mike Schilling]

I had to write a standard C to IBM mainframe converter a few years ago
(yikes, 1990!).

Good! (That I'm not the only one who does that.)

 

[Esmond Pitt]

In that case, they went backwards. Because the whole “raw types†concept
detracts from and weakens the coherence of the type system.

It provides backwards compatibility. Without that the product would be
unusable. It is possible to wish that the entire product was designed at
the same time, but it wasn't. In any case your contention was mistaken.

The designers also went forwards a very considerable distance by
providing generic classes that have provable type relationships among
them. C++ simply doesn't have that. You need to stop overlooking this point.

 

[Esmond Pitt]

Intel brought quite a few innovations in quite early, many of which went
nearly unnoticed for a while. The '286 and up have privilege rings and
support for multitasking in the hardware, for example. Only a couple of
OSes really used that stuff back then.

Exactly, and neither DOS nor Windows 2/3 being in that list.

 

[Lawrence D'Oliveiro]

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.

Intel had the volume advantage, that’s all. And it got the volume from
DOS/Windows, nothing else.

 

[Lawrence D'Oliveiro]

Exactly, and neither DOS nor Windows 2/3 being in that list.

Nobody seriously used that stuff, because none of it was of any use.

The only OS designed to try to make use of it, OS/2, flopped.

 

[Andreas Leitgeb]

Because the whole “raw types†concept detracts from and weakens
the coherence of the type system.

The "problem" about type-erasure is over-rated.

Suppose, an instance created so: Object o = new ArrayList<String>();
actually "knew" that it was an ArrayList of Strings (and not just
that it was an ArrayList, as it does now).
Then you would get a *runtime*-Error, if you tried to cast "o" to
ArrayList<Integer>, later. But generics aren't about runtime errors.
They are about being able to prevent some runtime-errors, by turning
them into compile-time errors. So, giving *still runtime*-errors for
casting between generic types of incompatible parametrizations is only
little win over giving runtime-errors on element-use.

 

[Lew]

The "problem" about type-erasure is over-rated.

Suppose, an instance created so: Object o = new ArrayList<String>();
actually "knew" that it was an ArrayList of Strings (and not just
that it was an ArrayList, as it does now).
Then you would get a *runtime*-Error, if you tried to cast "o" to
ArrayList<Integer>, later. But generics aren't about runtime errors.
They are about being able to prevent some runtime-errors, by turning
them into compile-time errors. So, giving *still runtime*-errors for
casting between generic types of incompatible parametrizations is only
little win over giving runtime-errors on element-use.

I'm very glad you made that point. I am glad we have type erasure in Java.
It forces you to deal with type assertions at compile time.

The problem with reifiable types is that it's too easy to do a half-assed job
of your type analysis, thus resulting in the runtime errors to which Andreas
alludes. Besides, all you need to do to get runtime typing is to include a
runtime type token as a final member of your class and Bob's your uncle. Like
so much else in Java, that just means you have to *think* and act for
yourself, and type a few extra lines of code. Don't sprain your finger with
that extra typing, whiners!

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

 

[Tim Slattery]

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

That's a bit backwards! The architecture existed, the OS had to deal
with it.

 

[Arved Sandstrom]

[ SNIP ]

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.

You've got a very optimistic definition of "portable" happening there.
It may come as a surprise to you, but all sorts of #ifdefs and
platform-specific configure scripts and makefiles don't mean that you've
got portable code - all of that is a response to the fact that you've
got _non-portable_ code.

AHS

 

[Esmond Pitt]

Nobody seriously used that stuff, because none of it was of any use.

Windows 95 used it, ditto 98, and every version of NT. Ditto NetWare 4.

The only OS designed to try to make use of it, OS/2, flopped.

For that reason?

 

[Lew]

Windows 95 used it, ditto 98, and every version of NT. Ditto NetWare 4.

For that reason?

That quote is out of context, but if "Lawrence D'Oliveiro" was saying that use
of clever Intel tricks like hardware multitasking and privilege rings were
used only by OS/2 (is that what he said? I missed his post.), the other OSes
you cite aren't the only ones, either. QNX, for example, was doing that on
the '286, and they're still very much in business, too.

They also leveraged the segmented architecture quite nicely. Typically,
multiple instances of the same program shared the code segment and only
allocated individual data segments. We put three simultaneous users on
terminals into the same application on a '386 with 2 MB of RAM and it ran like
a bat out of hell and never felt pinched for memory.

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

 

[Sulfide Eater]

That quote is out of context, but if "Lawrence D'Oliveiro" was saying
that use of clever Intel tricks like hardware multitasking and privilege
rings were used only by OS/2 (is that what he said? I missed his post.),
the other OSes you cite aren't the only ones, either. QNX, for example,
was doing that on the '286, and they're still very much in business, too.

QNX? That's even more obscure than OS/2 is!

Fact is, nothing with non-micoscopic market share used those features of
the 80286.

 

[Jef]

Number of pages is not a perfect indicator of complexity, but gives a
good estimation.

The main problem of your comparison is that the C++ standard refers a
lot to the C standard. A standalone C++ standard would be a lot
bigger.

A second point to take into account in your comparison is that the C++
standard contains nothing about threads and concurrency. This subject
is a significant part of java standard. It will be a huge part of next
C++ standard.

Java is definitively a much simpler language than C++, even with
generics and huge standard libraries.