Java vs C++

[Lawrence D'Oliveiro]

As explained numerous times then Java generics and C++ templates
are somewhat different.

The only differences arise from limitations of Java, nothing more.

 

[Lawrence D'Oliveiro]

L is an instance of a class. List<String> is an instance of a type, a
type that is distinct from List (the raw type or the class type).

If you're having this much problems understanding me ...

Use the terms as they are defined in the Java Language Spec, and we can all
get along fine.

 

[Joshua Cranmer]

The only differences arise from limitations of Java, nothing more.

That is not an assertion you can make. Java generics and C++ templates
are different because their designers wanted them to be different. It
would totally have been possible to implement C++ templates in Java--but
the designers decided that was not what they wanted to do. I don't know
what they would have done if they had added generics from the start, but
given all of the issues seen with templates, I am willing to guess that
it would still act nothing like templates do (i.e., as Java generics do
know, just with fully reified types).

 

[Arne Vajhøj]

See, you cannot even distinguish between “defined†and “implementedâ€.

You does not seem to have understood how Java generics are defined.

Such an implementation would not have been compliant.

In fact I think it would have been useless.

Arne

 

[Arne Vajhøj]

The only differences arise from limitations of Java, nothing more.

No. The differences arise from different decisions on what they
wanted.

Arne

 

[Lawrence D'Oliveiro]

Either Python is a simple language or the language reference is not
very detailed.

Go on, study the references for yourself, even get some experience with the
language, then let us know your verdict.

I am not sure that comparing a language reference with a standard
spec gives much meaning.

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

And the C spec leaves a lot of things to implementations.

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

 

[Lawrence D'Oliveiro]

No. The differences arise from different decisions on what they
wanted.

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

 

[Lawrence D'Oliveiro]

Possible. But if two template usages are compiled separatetly,
then it is not possible.

Exercise for the reader: explain why Arne Vajhøj is wrong. For extra credit,
list the implicit preconceptions that might have led to such a wrong
conclusion.

 

[Mike Schilling]

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

"God, if only we could have gotten code bloat and terminally confused the
separation between compiler and linker!"

 

[Mike Schilling]

Exercise for the reader: explain why Arne Vajhøj is wrong. For extra
credit,
list the implicit preconceptions that might have led to such a wrong
conclusion.

Arne is assuming that compilation and linking are separate phases. This was
one of the original design goals of C++, as you might recall from
Stroustrup's _Design and Evolution of C++_: that the C++ compiler produce
object code that the standard system linker could process. . It's no longer
true in many C++ development systems, precisely because templates make that
impossible to achieve with any efficiency.

 

[Lew]

"Lawrence D'Oliveiro" spat:
"Exercise for the reader" because the writer couldn't come up with any logical
or reasoned arguments, so he waves his hands and exercises trollishness instead.

What a maroon!

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

 

[Joshua Cranmer]

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

Writing portable code in C pretty much requires you to do hefty
compatibility layers. Many projects use typedefs to get proper-sized int
variables (you can't use stdint.h, as MSVC doesn't implement it, as of
MSVC 9.0). Anything more complex than basic I/O requires the use of
other, largely incompatible layers, for common things like
multithreading, asynchronous I/O, network I/O, etc. Let's not even get
into basic GUIs.

And even then, a careful reading of the C standard would reveal that it
gives very few absolute requirements of stuff, so that I could make
size_t be an 800-bit integer and still follow the standard, as well as
probably breaking everyone's so-called "portable C" code.

 

[Thomas Richter]

Why, what do compilers normally do?

Generate source code, or rather, evaluate expressions at compile time
rather than run time. Compilers usually take the source code and create
executable code from that, but the C++ template system allows you to
instruct the compiler to do parts of this evaluation while compiling.

So long,
Thomas

 

[Thomas Richter]

The fact remains, there IS an equivalent to ClassCastException in C++.

The fact remains that this is irrelevant to the discussion. Templates
aren't used like this in C++, and the C++ compiler doesn't insert a type
check into the binary to see whether the types match. The type check is
done at compile time. 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. It thus also
works quite different.

Greetings,
Thomas

 

[Thomas Richter]

"Lawrence D'Oliveiro" spat:

"Exercise for the reader" because the writer couldn't come up with any
logical or reasoned arguments, so he waves his hands and exercises
trollishness instead.

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.

Greetings,
Thomas

 

[Silvio]

It is 8086 architecture not 80286 architecture.


Windows has nothing to do with CPU architecture.

And the problem Silvio talks about (undefined sizes) is
not related to segmented memory.

Arne

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.

 

[Lawrence D'Oliveiro]

Writing portable code in C pretty much requires you to do hefty
compatibility layers.

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

Many projects use typedefs to get proper-sized int variables (you can't
use stdint.h, as MSVC doesn't implement it, as of MSVC 9.0).

How sad for MSVC...

 

[Lawrence D'Oliveiro]

Generate source code ...

Really??

 

[Lawrence D'Oliveiro]

Heck, they had BigInteger from the outset and could have gone so far as
to include a true numeric tower, implicit conversions all the way up to
BigInteger ...

Which is what Python did.

 

[Lawrence D'Oliveiro]

It is not an assumption about 32 bit architecture. 32 bit
architecture limits it more than the Java rule.

But the Java rule is the limitation now.